На підприємстві три системи. Продажі ведуть у CRM, склад — в обліковій, сайт живе своїм життям. Між ними ходить менеджер із вивантаженням у форматі Excel. Кожна помилка при перенесенні спливе через тиждень у вигляді відвантаженого товару, якого немає на залишках, або замовлення, про яке склад дізнався в день відгрузки.
Парадокс у тому, що кожна система окремо працює нормально. Проблема виникає рівно в точках стику — і саме там немає нікого відповідального, бо формально це «не моя зона».
Інтеграція прибирає людину з місця, де вона працює копіювальником. Дані переходять між системами самі — за розкладом або в момент події.
Впровадження CRM системи
CRM без зв’язку з обліком перетворюється на записник із контактами. Менеджер не бачить реальних залишків, не знає стану оплати, не може порахувати ціну з урахуванням чинних умов клієнта — і йде питати в бухгалтерію. Через місяць він починає вести паралельну табличку, а CRM заповнює постфактум «для звіту».
Інтеграція CRM з обліковою системою вирішує це: номенклатура, залишки, ціни та стан взаєморозрахунків підтягуються з обліку, а створене замовлення йде у зворотному напрямку. Менеджер працює в одному вікні й бачить актуальні дані.
| Що передається | Напрямок | Періодичність |
|---|---|---|
| Номенклатура та ціни | Облік → CRM | За розкладом, зазвичай раз на кілька годин |
| Залишки на складах | Облік → CRM | Часто, аж до реального часу для критичних позицій |
| Контрагенти та договори | В обидва боки | За подією створення або зміни |
| Замовлення клієнта | CRM → Облік | У момент оформлення |
| Стан оплати та борг | Облік → CRM | За розкладом або за подією проведення оплати |
| Відвантаження | Облік → CRM | За подією |
Впровадження ERP для виробництва
Виробництво відрізняється від торгівлі глибиною ланцюга. Між закупівлею сировини та відвантаженням готової продукції лежать переробка, зміна одиниць виміру, втрати, побічна продукція, повернення в переробку. Впровадження ERP для виробництва означає, що цей ланцюг стає простежуваним від партії сировини до конкретного відвантаження.
Ми впроваджуємо ERP поетапно, а не одним великим запуском. Причина проста: комплексні впровадження «все й одразу» найчастіше зриваються на етапі, коли персонал відмовляється працювати по-новому в розпал сезону, і підприємство відкочується до старого порядку, втративши бюджет і рік часу.
| Етап впровадження | Що закривається | Коли переходити далі |
|---|---|---|
| Перший контур | Найбільш проблемна ділянка — зазвичай склад або виробничий облік | Коли дані в системі збігаються з фактом |
| Другий контур | Суміжний процес: закупівлі або продажі | Коли персонал першого контуру працює без нагадувань |
| Третій контур | Собівартість і управлінська звітність | Коли первинні дані стабільно достовірні |
| Розширення | Інтеграції з обладнанням, аналітика, планування | За наявності запиту від бізнесу, а не «бо є в системі» |
Обмін даними між системами
Інтеграція через REST API
Основний спосіб зв’язку сучасних систем. Дані передаються в момент події: створили замовлення на сайті — воно одразу з’явилося в обліку. Ми реалізуємо інтеграцію систем через REST API як із готовими сервісами, у яких є документований інтерфейс, так і з самописними рішеннями, для яких доводиться писати шар обміну з нуля.
Інтеграція сайту з обліковою системою
Найчастіший сценарій: каталог і залишки з обліку йдуть на сайт, замовлення з сайту — назад в облік. Знімає подвійне введення і прибирає ситуацію, коли клієнт замовляє те, чого фізично немає на складі.
Для B2B-сайтів додається персональне ціноутворення: клієнт бачить свої ціни за договором, а не загальний прайс, і свій стан взаєморозрахунків.
Зв’язок із зовнішнім обладнанням
Обмін даними між системами не обмежується програмним рівнем. Ваги, системи контролю доступу, GPS-трекери, LPR-камери, термінали збору даних — усе це джерела даних, які теж мають потрапляти в облік без ручного введення.
Це наша основна компетенція: ми робимо і облік, і обладнання, тому зв’язати їх для нас звична задача, а не суміжна, яку доводиться передавати іншому підряднику з подальшим з’ясуванням, хто винен у нестикуванні.
Як ми працюємо
- Аудит наявних систем: що працює, в якому вигляді, які дані де зберігаються, хто чим користується насправді.
- Схема обміну: які об’єкти передаються, в якому напрямку, з якою періодичністю, що вважається джерелом істини при конфлікті даних.
- Розробка та тестування на копії даних, а не на робочій базі.
- Запуск і паралельна робота: певний час старий порядок зберігається як страховка.
- Супровід: обмін даними потребує спостереження, особливо в перші місяці — змінюється структура довідників, з’являються нові типи операцій.
Питання джерела істини звучить формально, але саме воно вирішує долю проєкту. Якщо не домовитися заздалегідь, чия цифра головна при розбіжності, обмін почне «воювати» сам із собою, перезаписуючи дані по колу.
Ознаки, що вам потрібна інтеграція
| Симптом | Що за ним стоїть |
|---|---|
| Хтось щодня переносить дані з однієї системи в іншу | Оплачувана ручна праця там, де має працювати обмін |
| Менеджер уточнює залишки в бухгалтерії | CRM не бачить обліку, дані застарілі за визначенням |
| Замовлення з сайту обробляються з затримкою в день | Немає автоматичної передачі, все тримається на людині |
| Цифри в двох системах не збігаються, і незрозуміло, яка правильна | Немає джерела істини, кожна система живе окремо |
| Дані з ваг або СКУД вводяться в облік вручну | Обладнання працює, але не підключене до обліку |
| Звіт для керівника збирається з кількох вивантажень | Немає єдиної точки, де дані вже зведені |
Від чого залежить вартість
Вартість інтеграції визначається не кількістю систем, а якістю їхніх інтерфейсів. Два сучасні сервіси з документованим API зв’язуються швидко й передбачувано. Одна самописна система без документації може коштувати дорожче за обидва попередні разом узяті — просто тому, що половина роботи піде на дослідження того, як вона влаштована.
- Наявність документованого API з обох боків — головний фактор.
- Кількість типів об’єктів обміну: передавати тільки замовлення значно простіше, ніж повний набір довідників, залишків і взаєморозрахунків.
- Односторонній чи двосторонній обмін. Двосторонній дорожчий не вдвічі, а більше — через логіку розв’язання конфліктів.
- Обсяг даних і потрібна швидкість. Обмін раз на добу і обмін у реальному часі — різні за складністю рішення.
- Стан довідників. Якщо номенклатура в двох системах не зіставляється, спершу доведеться навести порядок у ній.
Ризики, які варто врахувати заздалегідь
Інтеграція — це компонент, який ламається не сам по собі, а від змін у системах, які він зв’язує. Оновили конфігурацію, додали поле, змінили структуру довідника — і обмін перестає працювати або, що гірше, починає передавати дані неправильно.
Тому ми закладаємо в рішення дві речі: журналювання всіх операцій обміну та контроль розбіжностей. Перше дозволяє зрозуміти, що саме пішло не так, друге — виявити проблему до того, як вона проявиться в звітності.
Другий ризик — організаційний. Якщо обмін налаштували, а порядок роботи людей не змінили, з’являються паралельні процеси: частина даних йде через інтеграцію, частина — по-старому вручну. Результат гірший за вихідний стан, бо тепер незрозуміло, які цифри звідки взялися.
Питання, які ставлять найчастіше
У нас самописна система. Її можна інтегрувати?
Здебільшого так. Потрібен доступ до бази даних або можливість додати шар API. Оцінюємо на аудиті — саме тут вирішується, чи виправдана інтеграція, чи дешевше перейти на іншу систему.
Чи можна зробити обмін в один бік?
Так, і часто це правильне рішення на старті. Односторонній обмін простіший, дешевший і не створює конфліктів даних. Двосторонній додається пізніше, коли односторонній довів свою стабільність.
Що буде, якщо одна із систем тимчасово недоступна?
Коректно спроєктований обмін накопичує дані в черзі й передає їх після відновлення зв’язку. Це закладається на етапі схеми обміну, а не додається постфактум після першої аварії.
Скільки часу займає інтеграція?
Простий односторонній обмін між двома системами з документованим API — від двох тижнів. Двостороння інтеграція з самописною системою без документації може зайняти кілька місяців, значна частина яких піде на дослідження.
Чи потрібно міняти наявну CRM?
Не обов’язково. Якщо CRM влаштовує користувачів і має інтерфейс для обміну, дешевше інтегрувати її, ніж переучувати відділ продажів на нову.
Хто відповідає за обмін після запуску?
Ми беремо обмін на супровід. Це не той компонент, який можна встановити й забути: будь-яка зміна в одній із систем може зачепити передачу даних.