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