Чотири шляхи до однієї мети
Рішення прийнято: кінець ручному переносу замовлень між системами. І тут починаються інші проблеми, про які рідше говорять. Один постачальник пропонує інтеграцію через API. Другий переконує, що достатньо нічного експорту файлів CSV. Знакомий з галузі хвалить роботів RPA, які клацають на екран за людину, а оскільки частина документів і так надходить у форматі PDF, ще й спокушає OCR. Кожен із цих шляхів буває добрим. Жоден не є добрим всюди.
Як багато коштує саме переписування та як його підрахувати, описали у статті про те, скільки годин на тиждень команда втрачає на перенесення даних. Тут ми припускаємо, що розрахунок у вас уже є. Пора вибрати спосіб підключення.
API, або пряме з’єднання
Системи розмовляють одна з одною програмно: замовлення, записане в ERP, через момент опиняється в CRM, без участі людини. Це найтриваліша форма інтеграції, бо виробник системи розглядає API як офіційну угоду. Зміни заповідає, документацію та підтримку зберігає у зворотньому напрямку.
Чесні межі для одного з’єднувача зазвичай становлять 2-6 тижнів, а вартість залежить головним чином від кількості потоків та якості документації з обох сторін. Ми визнаємо відкрито: на старті API коштує більше, ніж вивантаження файлу, бо вимагає програмістської роботи та тестів. За це подальше підтримання є потім найдешевшим серед усіх чотирьох шляхів.
Вивантаження файлів, або простота з розкладом
Одна система кожної ночі зберігає файл CSV або XML, інша завантажує його вранці. Звучить архаїчно, але буває найбільш розсудливим: впровадження займає від кількох днів до двох тижнів і коштує найменше. Ціною простоти є затримка. Дані передаються один раз на добу і зазвичай в одному напрямку. Для передачі рахунків до бухгалтерії це достатньо, для стану складу в інтернет-магазині вже ні.
OCR, коли дані надходять у вигляді зображення
Рахунки від сотень постачальників, скани протоколів, папір. OCR з шаром AI витягує з документів поля і зберігає їх у системі. Цей шлях має сенс, коли з іншого боку немає з чим інтегруватися, бо надавачів десятки і не нав'язуємо їм формат. Ефективність ніколи не становить 100%, тому обов'язковою частиною впровадження є процес верифікації винятків людиною. Реальний час: 3-8 тижнів, залежно від різноманітності документів.
RPA, тобто робот, який клацає як людина
Скрипт логується до програми і виконує в інтерфейсі ті самі рухи, які робив працівник. Перевага є очевидною: не потрібно API чи згоди виробника, а діюче демо створюється за кілька днів. Вада теж: робот прив'язаний до вигляду екрану. Оновлення системи зсуває кнопку на 20 пікселів і процес зупиняється, часто безголосно. На нашу думку, RPA повинно бути останньою, а не першою опцією, бо низька вартість запуску компанії сплачують потім кожному місяці в утриманні та в нервах після кожної оновлення.
Таблиця порівняння
| Критерій | API | Експорт файлу | OCR | RPA |
|---|---|---|---|---|
| Коли має сенс | обидва системи мають API | дані потрібні раз на добу | документи від багатьох відправників | закрита система, відсутній API |
| Час впровадження | 2-6 тижнів | дні до 2 тижнів | 3-8 тижнів | дні (демо), тижні (продуктивно) |
| Вартість запуску | середня | низька | середня до високої | низька |
| Вартість підтримки | низька | низька, але вимагає власника | середня (верифікація винятків) | висока |
| Хиткість | низька | низька | середня | висока |
| Актуальність даних | секунди | доба | хвлини до годин | хвлини |
Три пастки, які ми бачимо найчастіше
Перша: RPA на інтерфейсі, який змінюється. Якщо постачальник системи випускає оновлення кожний квартал, робот буде ламатися кожний квартал. Бюджет на його нагляд може перевищити вартість гідного конектору API.
Друга: експорт CSV без власника. Файл перестає генеруватися, ніхто не отримує сигнал тривоги і протягом двох тижнів компанія працює на застарілих даних. Експорт файлу мусить мати ім'яно вказаного опікуна та автоматичний сигнал тривоги, коли файл не надходить.
Третя: OCR на документах, які могли б прийти цифрово. Якщо контрагент видає фактури в системі з API або через KSeF, читання його PDF-файлів машинно означає платити за штучну проблему. Дешевше домовитися про формат обміну.
Дерево прийняття рішень у чотирьох кроках
- Чи мають обидва системи задокументовані API? Виберіть API. Вищий початковий кошт окупиться під час обслуговування.
- API відсутній, але даних достатньо раз на день? Експорт файлів з власником та сигналізацією.
- Чи приходять дані у вигляді документів від багатьох зовнішніх надавачів? OCR з процесом верифікації винятків.
- Чи система закрита, постачальник не співпрацює, а дані необхідні оперативно? Тільки зараз RPA, з бюджетом на обслуговування та планом переходу на API, як тільки це стане можливим.
На практиці великі впровадження змішують підходи: API між ERP та CRM, OCR для рахунків постачальників, експорт файлів до складу даних. Це нормально. Головне, щоб кожен потік даних мав інструмент, обраний відповідно до його характеристики, а не одне улюблене інструмент постачальника.
Як ми це робимо в ESKOM AI
У ESKOM AI вибір шляху інтеграції є частиною аналізу, а не припущенням заздалегідь. Ми перевіряємо інтерфейси ваших систем, потім команда спеціалізованих агентів AI виконує більшу частину інженерної роботи при створенні з'єднувача, а вся система проходить повний спектр тестів: юніт-тести, інтеграційні тести, E2E, інтерфейсні, безпекові та продуктивні тести. Дякуючи автоматизованому процесу виробництва, ми говоримо про тижні, а не квартали. Як такий проект виглядає крок за кроком, ми описали у статті про те, як поєднати ERP, CRM та власну aplikaciju за декілька тижнів.
Якщо ви стоїте перед вибором однієї з чотирьох доріг, домовтеся про безплатну консультацію через форму на eskom.ai/pl/kontakt. Напишіть, які системи ви хочете поєднати та як швидко дані повинні надходити — ми повернемось з рекомендацією конкретної дороги та чесною оцінкою.