Програмного Франкенштейна не купують готовим. Його збирають із найкращих намірів. Бухгалтерії потрібна своя конфігурація, кадровикам — зарплата, менеджерам — CRM, складу — WMS, а покупцям — сайт. Кожне рішення має свою задачу. «Ми просто інтегруємо їх», — каже команда. Саме тут і починається історія про шви.
Один продаж, кілька версій події
Менеджер створює замовлення в CRM. Склад має зарезервувати товар, облікова система — отримати дані для відвантаження й документів, а сайт — показати покупцеві правильний статус. Якщо кожна система веде власну базу, ці дії залежать від того, як налаштовані обміни.
Уявімо, що повідомлення про замовлення надійшло двічі. Чи створить склад два резерви? А якщо замовлення дійшло раніше, ніж картка нового товару? Чи стане воно в чергу, чи загубиться без пояснення? Різні цифри в CRM і на складі можуть бути наслідком затримки, різних правил розрахунку або помилки зіставлення довідників. Доки не видно, де саме розійшлися дані, відповідь «це обмін» нічого не пояснює.
Що насправді коштують шви
Підтримка інтеграції починається після її запуску. Потрібно стежити за чергою, відновлювати обмін після збою та перевіряти його після оновлень. Коли лише один програміст знає, як безпечно повторно передати документ, його відсутність стає ризиком для продажів і складу.
Окрема система може бути доречною, наприклад, коли склад потребує спеціалізованої WMS. Тоді кожному обміну потрібні відповідальний, журнал помилок і правило повторної обробки. Інакше команда дедалі більше часу проводить між системами, звіряючи документи, замість роботи з клієнтом.
Окремі конфігурації та спільні дані
Описаний сценарій стосується підприємств, які поєднали кілька окремих баз 1С/BAS. У лінійці BAS є також BAS ERP, для якої виробник описує інтегровані контури управління й обліку. Тож при порівнянні важливо дивитися, як саме розгорнуто систему на підприємстві.
У документації K2 ERP описано модель, у якій модулі використовують спільні довідники та дані в єдиній базі. Якщо продажі й склад працюють у такому контурі, їм не треба пересилати один одному окремі копії довідника товарів. Зовнішні сервіси й окремі бази все одно потребують інтеграцій. Спільний контур зменшує кількість внутрішніх швів, за якими треба стежити.
Як знайти слабке місце до міграції
- Візьміть одне замовлення й простежте його від CRM до складу, фінансів і сайту. Для кожного кроку визначте, яка система є джерелом даних.
- На тестових даних повторно передайте те саме замовлення, потім змініть кількість або скасуйте його. Звірте документи, резерви та статуси.
- Перевірте, чи бачить відповідальний помилку, чи може відновити обмін і чи лишається після цього одна узгоджена версія події.
Якщо менеджер бачить замовлення, склад — його резерв, а бухгалтер — пов’язаний документ, система витримала принаймні один наскрізний сценарій. Саме такі перевірки показують, де шов справді потрібен і чи зможе команда підтримувати його після запуску.
