Проблемът при голям каталог не е броят артикули. Проблемът е, че една и съща характеристика идва под три имена, в три мерни единици и понякога на друг език.
Онлайн търговец с каталог от около двадесет хиляди артикула работи с четиридесет доставчика. Всеки изпраща данните си в собствен формат, различни колони, различни имена на атрибути, липсващи описания. Нов артикул стига до продажба за няколко дни, защото някой трябва да попълни липсващото на ръка. През кампаниен период изоставането расте, вместо да намалява. Същото описание се повтаря по три пъти, веднъж за магазина, веднъж за ERP и по веднъж за всеки маркетплейс със свои изисквания.
Броят доставчици е това, което определя дали казусът е ваш. Двадесет хиляди артикула от един доставчик са по-лесни от две хиляди от четиридесет.
Шест стъпки в двата случая. Разликата е дали човек попълва или одобрява.
Всеки артикул минава през ръчно попълване.
Данните са попълнени. Човек одобрява партида, не ред.
Одобрението е на партида, не на артикул. Поединично се разглеждат само редовете, които не са минали проверките, обикновено малка част от файла.
Не писането на описания е тясното място. Тясното място е решението към коя категория принадлежи артикул, чието наименование не прилича на нищо в каталога, и това решение се взема наново при всеки нов доставчик, защото не е записано никъде.
Системата не променя цени и не пуска продукт в продажба самостоятелно. Тя подготвя данните и маркира какво липсва. Публикуването и всяка промяна, която клиентът вижда веднага, остават решение на отговорника за каталога.
Веригата е една и съща във всички наши проекти. Разликата е какво стои във всяко звено.
Четири звена между фийда и магазина.
Бихме измервали: време от файл до публикуван артикул, дял артикули с пълни атрибути, откази от маркетплейс
Разделението е изрично, защото от него зависи какво може да се обещае.
Преобразуването на атрибути е работа за правило, не за модел, то трябва да дава един и същ резултат всеки път.
Изключенията не са грешки в проекта. Те са това, което определя дали процесът ще работи в реална среда.
Второто изключение е това, което прави системата по-добра с времето, всяко решение на човек става правило.
Показателите се сравняват с изходно състояние, измерено преди началото.
Колко бързо продуктът стига до продажба.
Дали данните са завършени.
Какво се случва надолу по веригата.
И къде не си заслужава, това е също толкова полезно да се знае.
Ако още нямате единна структура на атрибутите, това е първата стъпка и тя си струва независимо от автоматизацията.
Редовният пример и примерът с проблем показват защо един структуриран резултат още не е разрешение за действие.
Това е работеща демонстрация на проверките след извличане на данните. Използва примерен структуриран резултат, не изпълнява AI модел, OCR или връзка с CRM/ERP и не изпраща въведеното към сървър. Използвайте само тестови данни.
Изберете пример и натиснете „Провери данните“.
Дори при успешна проверка последната стъпка е човешко одобрение. Бутонът сменя само тестовия статус на тази страница. В реална система правилата, разрешените действия и изключенията се договарят предварително.
Илюстративен сценарий. Описаният случай е примерна структура на работен процес, а не резултат при конкретен клиент. Показателите описват какво бихме измервали при реално внедряване. Измерени данни публикуваме само със съгласие на клиента и с описана методология.
Това число казва повече за възможния ефект от размера на каталога.
Този примерен сценарий може да бъде отправна точка за собствен проект. Конкретният обхват, достъпите и критериите за приемане се уточняват за вашите системи.
Ползваме бисквитки само за да разберем как се ползва сайтът. Без съгласие не се зарежда нищо. Подробно в политиката за бисквитки.
