У кожній торговельній чи виробничій компанії є людина, яка «все знає про товари». Вона памʼятає, що ось ця труба підходить лише до фітингів іншого виробника, що фарба з нової партії трохи темніша, що в цієї моделі насоса два варіанти приєднання і клієнти постійно їх плутають. В обліковій системі при цьому записано назву, артикул, ціну й залишок. Усе інше живе в голові цієї людини. Поки вона на місці, компанія працює. Коли вона йде у відпустку, починаються повернення, пересортиця й дзвінки розлючених клієнтів. Я називаю це хворобою тонкої картки товару і зустрічаю її майже в кожному проєкті.
Чому типові системи описують товар так бідно
Типова облікова система проєктується під середню компанію, якої не існує. У неї є поля, спільні для всіх: найменування, одиниця виміру, ціна, штрихкод. Це розумно, бо постачальник системи не може заздалегідь знати, що Ви продаєте. Але в реальному бізнесі товари дуже різні. Одяг має розмір, зріст, склад тканини й сезон. Електроніка має напругу, потужність, розʼєми й сумісність. Будматеріали мають клас міцності, фракцію й витрату на квадратний метр. Спробуйте запхати все це в одне поле «Опис», і за рік Ви отримаєте звалище тексту, за яким неможливо ні шукати, ні фільтрувати, ні будувати звіти.
Зазвичай компанії виходять зі становища двома способами, і обидва погані. Перший: замовляють у розробників додати в базу ще двадцять колонок під конкретні характеристики. За пів року зʼявляється нова категорія товарів, і треба ще двадцять. Таблиця розростається до сотні полів, більшість яких для кожного конкретного товару порожні. Другий спосіб: ведуть характеристики в окремій таблиці Excel поруч із системою. Це працює рівно до першої розбіжності версій, а розбіжність настає приблизно на другий день.
Конструктор форм: характеристики як дані, а не як код
Правильне рішення відоме давно, і воно елегантне: характеристики товару мають бути не частиною структури бази, а даними, які налаштовує сам бізнес. Це і є конструктор форм. Менеджер з асортименту, а не програміст, створює для групи товарів набір полів: «Розмір» зі списком значень, «Потужність» числом з одиницею виміру, «Сумісність» посиланням на інші товари. Кожна група отримує свою картку, свою форму введення, свої фільтри. Нова категорія товарів більше не потребує розробки, вона потребує десяти хвилин налаштування.
Я люблю порівнювати це з бібліотекою. Можна надрукувати картку каталогу з фіксованими графами «автор, назва, рік» і змушувати бібліотекаря вписувати все інше на звороті дрібним почерком. А можна дати йому змогу для кожного розділу визначити, що важливо: для карт масштаб і регіон, для нот інструмент і тональність, для журналів номер випуску. Бібліотека від цього не стає складнішою. Вона стає точнішою.
Облікова система, у якій не можна описати Ваш товар так, як його розуміють Ваші клієнти, обліковує не товар, а його тінь.
Що дає детальний опис бізнесу
Перший ефект видно на складі й у продажах одразу: менше помилок під час підбору. Коли товар має структуровані характеристики, менеджер не шукає з памʼяті, а фільтрує: потрібен насос такої-то потужності з таким-то приєднанням, ось три відповідні позиції, ось їхні залишки. Пересортиця й повернення зменшуються, бо знання перестає залежати від однієї людини.
Другий ефект: якісні картки для інтернет-магазинів і маркетплейсів. Майданчики вимагають дедалі більше атрибутів, і якщо вони вже є в обліковій системі, вивантаження стає технічною операцією, а не тижнем ручного заповнення. Покупець на сайті бачить фільтри за реальними характеристиками й знаходить товар, а не йде до конкурента, у якого фільтри є.
Третій ефект, про який рідко думають заздалегідь: аналітика. Коли характеристики зберігаються як дані, можна відповісти на запитання, які раніше потребували ручного розбору. Які розміри продаються краще в якому сезоні. Які параметри найчастіше шукають і не знаходять. На яких характеристиках у нас найбільше повернень. Це вже не облік, це управління асортиментом.
Підводне каміння, про яке варто знати
Гнучкість має ціну, і було б нечесно про це змовчати. Конструктор форм легко перетворити на хаос, якщо не домовитися про правила. Якщо кожен менеджер створюватиме поля як йому зручно, за рік у системі будуть «Колір», «колір товару», «Цвет» і «Відтінок», і всі чотири означатимуть те саме. Тому налаштування характеристик має бути в руках одного відповідального, а значення за можливості обиратися з довідників, а не вводитися вільним текстом.
Другий камінь технічний: зберігання довільних характеристик потребує продуманої структури бази, інакше пошук і звіти почнуть гальмувати на десятках тисяч товарів. Це розвʼязне завдання, але розвʼязувати його треба архітектурно від самого початку, а не латати, коли склад уже розрісся.
Що робити завтра
Візьміть пʼять найпроблемніших товарних груп, у яких найчастіше бувають помилки й повернення. Запитайте в тієї самої людини, яка «все знає», які три-пʼять характеристик справді важливі для правильного підбору в кожній групі. Запишіть їх. Найпевніше, Ви здивуєтеся, наскільки коротким вийде список і скільки проблем він закриває.
У Forma, нашій ERP-платформі, розділ продуктів влаштований саме так: для товарів налаштовуються власні поля й довідники значень, є категорії, типи, пакування й генерація артикулів, а склад і продажі працюють із цими даними напряму. Якщо ж у компанії особлива предметна область, у Systems ми проєктуємо модель товару під неї, а Fractal генерує структуру й інтерфейс за описом. Але в будь-якому разі перший крок однаковий: витягти знання про товар із голови однієї людини в систему, де воно працюватиме на всіх.
