Не всі інтеграції працюють, як потребує бізнес

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

Чому інтеграції у шаблонній ERP-системі рідко лягають на процес

У типовій ERP-системі інтеграція універсальна: один типовий сценарій для усіх. Для вендора це логічно — він робить одне рішення під типовий бізнес. Для вас — ні, бо ваш процес відрізняється саме в тих деталях, яких вендор не бачив.

І ці деталі є частиною вашого щоденного процесу.

Момент запуску. Хтось створює ТТН одразу з рахунку. Хтось — тільки після того, як склад зібрав замовлення. Хтось — усі разом наприкінці зміни. Для самої Нової Пошти це все валідні сценарії. Для шаблонного модуля — один стандартний.

Реакція на помилку. API повернуло збій — лишити документ у статусі «помилка», повернути в чернетку, ескалувати менеджеру чи повторити через годину? У шаблонній ERP це вже вирішили за вас.

Те, що прилітає назад. Статуси посилок, банківські виписки, фіскальні чеки повертаються в систему. Що з цим робити, коли показувати і кому — теж частина процесу.

Кілька організацій, складів, ключів. Готові модулі часто розраховані на одну юрособу й один ключ. Додайте другу — починаються обхідні шляхи.

Це не рідкісні випадки. Це звичайне життя бізнесу на 100+ людей.

У нас інтеграція — частина конфігурації

Інший підхід — не зашивати інтеграцію в ядро, а описувати її в конфігураторі під конкретний процес. Так само, як ви описуєте документ, звіт чи роль.

На прикладі Нової Пошти: ми не обираємо за вас, коли створюється ТТН. Ви вказуєте — «створюй, коли статус відвантаження змінюється на такий-то» — і так воно працює. У сусіднього клієнта той самий API спрацьовує з іншого документа і в іншому обʼємі. Одна інтеграція — дві різні реалізації.

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

Як це технічно влаштовано, ми показували на прикладі Checkbox. Ця стаття — про те, чому сам підхід «прошити один сценарій» не працює, коли у кожного бізнесу процес відрізняється.

Що вам з цього?

Зможете адаптувати інтеграцію під свої процеси, а не навпаки.

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

Новий сервіс із публічним API додається тоді, коли він потрібен вам, а не коли дійшла черга у вендора.

Клієнт із доступом до конфігуратора веде частину інтеграцій самостійно, без звернень до підтримки.

Висновок

Інтеграція має точно лягати на вашу модель роботи. У шаблонній ERPшці ця точність завжди приблизна. Тут ви визначаєте її самі.

Хочете подивитись, як це виглядає на ваших процесах — записуйтесь на демо.