Четыре пути к одной цели
Решение принято: конец ручному переносу заказов между системами. И тут начинается вторая проблема, о которой говорят реже. Один поставщик предлагает интеграцию через 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 и собственное приложение за недели.
Если вы стоите перед выбором одного из четырёх путей, запишитесь на бесплатную консультацию через форму на eskom.ai/pl/kontakt. Напишите, какие системы хотите соединить и насколько быстро должны течь данные – мы вернёмся с рекомендацией конкретного пути и честной оценкой стоимости.