Три системи - три правди про один товар: порядок у каталозі між обліком, CRM і сайтом

Магазин продає на власному сайті і ще на девʼяти майданчиках. Облік веде одна система, замовлення менеджери бачать в іншій, товари на сайті живуть у третій. Кожна з них називає той самий товар по-своєму.

Поки товарів мало, це дрібниця. Коли їх тисячі, CRM перестає впізнавати, що саме продали. Позиція в замовленні стає просто рядком тексту, а звіт «що продається найкраще» показує не всю картину.

У цьому проєкті треба було не написати ще одну інтеграцію, а навести порядок у тому, що вже є, і довести, що після цього він тримається.

99,66%

товарів у нових замовленнях впізнаються

970

назв виправлено за 23 хвилини, 0 помилок

11%

виручки, на яку раніше брехала аналітика

Проблема: три системи, три правди про один товар

Облікова система - джерело правди для назв, цін і залишків. Сайт - для фото й описів. CRM - місце, де менеджер працює із замовленням. Обмін між ними формально працював, але товар у CRM впізнавався лише тоді, коли його артикул точно збігався з карткою в каталозі.

Чому товари «губились» дорогою

🏷 Різні артикули

Короткий артикул на сайті і в обліку різний у кожній шостій парі
Сайт пише варіаціям артикул «батька», облік - свій на кожен колір
Електронні таблиці зрізають нулі на початку: 02206 стає 2206

📭 Дірки в каталозі

Товар продається, а картки в CRM немає
Позиція лишається текстом назавжди
Дірка росла щодня разом із продажами

🔀 Чужий товар

Чохол для килимка привʼязаний до гальмівних ручок
Синій шолом у CRM називається «червоний»
Продажі рахуються не на той товар

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

Як автоматизація це вирішує

Спершу виміряти, потім виправити, потім перевірити, що виправлене тримається. Кожен крок - на реальних даних через API, з резервною копією і з контрольним зрізом після.

Від хаосу в каталозі до контролю обміну

Три вивантаження → звірка артикулів → аудит замовлень

масове виправлення → вимоги до обміну → контрольні зрізи

Ключова ідея: виправити дані один раз мало, треба закрити джерело дірки

Разова дозаливка закриває сьогоднішню дірку, але завтра зʼявиться новий товар, і все повториться. Тому паралельно з виправленням ми написали вимоги до обміну для підрядника, що обслуговує облікову систему: картка товару має створюватись у CRM автоматично в момент, коли вона потрібна. Після того як підрядник це реалізував, ми звірили результат незалежним зрізом.

Що зроблено руками системи, а не людини

ЗвіркаПонад 21 тисяча рядків обліку проти 2,6 тисячі товарів сайту. Кожна пара розкладена по типах розбіжностей: норма, варіація, форматування, справді різні артикули

Назви970 назв у CRM приведено до облікових за 23 хвилини, 0 помилок. Там, де дві різні позиції мали однакову назву, до назви додано артикул

Картки114 відсутніх карток створено одним проходом з артикулами рівно такими, як вони приходять у замовленнях, - інакше привʼязка знову б відвалилась

КонтентКартки, створені обміном, приходили без фото, опису й категорії. 54 з них заповнено з сайту, лише в порожні поля

КонтрольРегулярні аудити замовлень: скільки позицій впізнано, чи немає дублів замовлень, чи не зʼявились хибні привʼязки

Що дістається людям

Менеджер відкриває замовлення і бачить товар із назвою з обліку, фото і ціною, а не рядок тексту. Власник отримує звіт по товарах, якому можна вірити. А там, де помилка сидить в обліку (синій шолом, записаний як червоний), вона не маскується, а чесно видна і передана тим, хто може її виправити.

Що це дало бізнесу

До робіт кожна девʼята-десята позиція в замовленнях не впізнавалась як товар, і на ці позиції припадало 11% виручки. На цю частку помилялись звіти по товарах, залишки й будь-який майбутній розрахунок маржі.

Скільки позицій у нових замовленнях впізнаються як товар

Серпень, до робіт86,4%

Перший тиждень вересня, після99,66%

З 2 вересня обмін не пропустив жодного товару. Дублів карток за артикулом - нуль, нових дублів замовлень - нуль. Єдина позиція без картки в усій CRM - службовий рядок «додатковий продаж», якому картка й не потрібна.

Чесно про межі. Близько 470 позицій серпневих замовлень так і лишились текстом: привʼязку заднім числом система не дозволяє створити, і це перевірено експериментально. Аналітика по товарах за серпень занижена назавжди. Собівартість з обліку в CRM досі не передається, тому «прибуток» у CRM поки дорівнює виручці - це передано підряднику як незакритий пункт вимог. Частина нових карток приходить із нульовою ціною. І близько сотні товарів, які продаються лише на маркетплейсах, лишаються без фото, бо їх немає на власному сайті.

Як це влаштовано всередині

Далі - інженерна частина

Наступний розділ пояснює, як система влаштована. Якщо вас цікавить лише результат, його можна пропустити - нижче є розділ про те, кому це підходить.

Уся робота - Python-скрипти, які читають і пишуть CRM через її API, і звірки вивантажень облікової системи й сайту. Кожен масовий запис має резервну копію стану «до» і файл «було → стало» по кожному товару, тож будь-яку зміну можна відкотити.

Технічні рішення, на яких усе трималось

ВимірПривʼязку позиції до картки вдалося виміряти напряму, запитуючи замовлення разом із пропозицією товару. На першому аудиті її не було видно взагалі, і це змінило всю методику

ЛімітиCRM ділить ліміт запитів з обміном облікової системи. Після першого перевищення ліміт власних аудитів знижено з запасом, наступні прогони пройшли без жодної відмови

КолізіїCRM вимагає унікальних назв. Дві різні позиції з однаковою назвою в обліку отримують артикул у назві, але лише там, де його там ще немає. Перша версія правила дописувала його двічі, - виправлено окремим проходом

АртикулиКартки створюються з артикулом рівно таким, як він приходить у замовленні, навіть якщо в ньому пробіл і скісна риска. Виправляти такий артикул можна лише одночасно в обліку і в CRM

АрхітектураДля подальших інтеграцій обрано читання з обліку через стандартний протокол і запис через власні HTTP-сервіси за жорсткими правилами. Пряма робота з базою обліку і готові шини відкинуті: перше ламається з кожним оновленням конфігурації, друге додає вендора і третю точку відмови

Межа відповідальності чесна: механізм автоматичного створення карток при обміні реалізував підрядник, що обслуговує облікову систему. Наша частина - аудит і методика виміру, звірка, масові виправлення, вимоги до обміну і незалежна перевірка результату.

Кому це підходить

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

Ознака, за якою легко перевірити, чи це про вас: якщо звіт «топ продажів» у CRM не збігається з тим, що ви бачите на складі, а в замовленнях трапляються товари без фото і без посилання на картку, - так, це про вас.

Автоматизація на брудних даних лише швидше множить помилки. Спершу порядок у каталозі - потім усе інше.