Как да централизираме продуктовите данни, без да забавяме екипите

Продукт се пуска на пазара с грешна бележка за съответствие. Клиент на едро вижда цените на дребно. Наличността е налична в ERP системата, но не е налична онлайн. Това рядко са изолирани грешки при публикуването. Те са симптоми на разединена собственост и неясен поток от данни. Да знаеш как да централизираш данните за продукта означава да създадеш една управлявана продуктова основа, която захранва системите, на които разчитат твоите екипи и клиенти.

За търговските фирми целта не е да се наложи всяко поле в едно приложение. Целта е да се определи къде се създава, одобрява, съхранява и разпространява всяка информация за продукта. Добре направена, централизацията намалява повторното въвеждане на ключове, защитава качеството на данните, скъсява циклите на стартиране и предоставя на всеки канал по-надеждна версия на каталога.

Защо разпръснатите данни за продукти се превръщат в оперативен проблем

Информацията за продуктите често се натрупва там, където екипът е имал нужда от нея първо. ERP системата съдържа кодове на артикули, разходи и налични запаси. Платформата за електронна търговия съдържа описания, изображения, колекции и настройки за търсене. Електронна таблица съдържа спецификации на доставчиците. Екипите по продажбите могат да поддържат специфични за клиента файлове с цени извън всички тях.

Тази настройка може да работи, когато каталогът е малък и промените са редки. Става скъпо, когато продуктите имат варианти, правила за съвместимост, техническа документация, множество складове, регионални асортименти или B2B цени. Всяка актуализация се превръща в задача за координация. Персоналът превъвежда стойностите на ръка, коригира специфични за канала изключения и отделя време за определяне кой запис е актуален.

Търговските разходи са по-големи от административните разходи. Неточните наличности водят до анулирани поръчки. Непоследователните атрибути правят филтрите по-малко полезни и намаляват откриваемостта на продукти. Липсата на документация забавя екипите по продажбите и обслужването. Ако новите продукти изискват петима души да работят с четири системи, скоростта на пускане на пазара се ограничава от вътрешната обработка на данни, а не от пазарните възможности.

Как да централизираме данните за продуктите: започнете със собствеността

Първото решение не е коя платформа да закупите. А коя система притежава всяка категория данни. Централизираната среда може да включва ERP, система за управление на продуктова информация, библиотека с цифрови активи, платформа за електронна търговия и хранилище за данни. Централизацията идва от ясни правомощия и контролирана синхронизация, а не от преструвката, че всяко приложение трябва да върши всяка задача.

Практическият модел на собственост обикновено изглежда така:

• ERP системата притежава SKU, референции на доставчици, разходи, статус на поръчките, складови наличности и често базови цени.
• PIM или персонализиран продуктов център притежава описания, спецификации, таксономия, атрибути за готовност за канали, взаимоотношения и статус на одобрение, насочени към клиента.
• Система за управление на цифрови активи или контролирана медийна библиотека притежава изображения, видеоклипове, сертификати, ръководства и права за ползване.
• Платформата за електронна търговия притежава подробности за представянето на каналите, правила за мърчандайзинг и специфични за магазина настройки.

Вашият точен модел зависи от начина, по който функционира вашият бизнес. Дистрибутор на части може да се нуждае от ERP, за да притежава данни за монтаж и обмен, тъй като те се поддържат от технически купувачи. Модна марка може да се нуждае от PIM, за да управлява богати атрибути, сезонни колекции, изображения и съдържание на ниво варианти. Търговска компания на едро може да изчислява договорни цени в ERP, докато публикува одобрени ценови листи в портал на дилъра.

Ключът е да се избегне споделена собственост върху едно и също поле. Ако и ERP, и магазинът могат да променят заглавието на продукт, някой в крайна сметка презаписва легитимна актуализация. За всеки критичен атрибут, идентифицирайте един източник на истина и направете низходящите системи потребители на тази стойност.

Изградете модел на продуктови данни, преди да изградите интеграции

Един чист модел на данни превръща неясна цел в работа по внедряването. Започнете с картографиране на продуктовите обекти, които вашият бизнес действително използва: родителски продукти, варианти, пакети, комплекти, резервни части, конфигурируеми продукти и сервизни елементи. След това документирайте как те са свързани.

Не се спирайте на обща електронна таблица с име, SKU, цена и изображение. Запишете полетата, които влияят на реалните оперативни решения и решения за покупка. Това може да включва размери, материали, информация за съответствие, минимални количества за поръчка, количества в кашон, съвместимост, срокове за изпълнение, ограничени правила за доставка, групи клиенти и държава на произход.

За всяко поле документирайте неговия формат, собственик, правило за валидиране и местоназначение. Например, атрибут за напрежение може да изисква числова стойност плюс мерна единица. Продукт не може да бъде публикуван, докато не получи одобрено основно изображение и не му бъде присвоена категория. Спрена от производство стока може да остане достъпна за търсене от съществуващи клиенти, но вече да не може да бъде поръчвана.

Тази работа разкрива несъответствия рано. Един екип може да използва 12-инчови, докато друг използва 12-инчови. Един доставчик може да изпрати номер на модел в поле, което друг нарича SKU. Нормализирането на тези стойности преди автоматизацията е далеч по-евтино от прехвърлянето на несъответстващи данни по всеки канал.

Изберете правилната централна система за каталога

PIM често е най-добрият център за каталог с много съдържание и множество канали. Той предоставя на екипите по търговия, продукти и маркетинг структурирани работни процеси за обогатяване, валидиране, локализация и публикуване. Той е особено полезен, когато хиляди продукти се нуждаят от последователни атрибути и много канали за продажби консумират една и съща информация.

Модел, базиран на ERP, може да бъде по-подходящ, когато оперативните записи са строго контролирани, съдържанието на продуктите е ограничено и екипът по продуктите вече поддържа надеждни данни за артикулите там. В този модел магазинът може да получава продукти, цени, наличности и основни атрибути директно от ERP, с контролиран процес за уеб съдържание.

Някои организации се нуждаят от персонализиран хъб за данни за продукти. Това е често срещано, когато стандартните PIM структури не побират сложни конфигурации, специфични за дилърите каталози, съвместимост на оборудването, регулирана документация или данни от доставчици, които изискват съществена трансформация. Персонализиран хъб може да прилага бизнес правила между системите, като същевременно предоставя на персонала интерфейс, който отразява действителния им работен процес.

Има компромис. Добавянето на PIM или персонализиран слой въвежда друга система за работа. Но разчитането на платформата за електронна търговия като универсален майстор може да направи интеграциите крехки и да постави управлението на оперативните данни в инструмент, създаден предимно за продажби. Правилният подход е този, който намалява неяснотата, без да създава ненужна администрация.

Свържете системите чрез надеждни и видими интеграции

Централизираните данни се провалят, ако синхронизацията е бавна, непрозрачна или трудна за възстановяване, когато нещо се повреди. Интеграциите на продукти трябва да преместват данните чрез дефинирани API, уеб куки, планирани задачи или опашки от събития, а не чрез рутинни CSV експорти и ръчни импорти.

Не всяко поле се нуждае от синхронизация в реално време. Наличността на инвентара и възможността за поръчка може да се нуждаят от актуализации в рамките на минути, особено за операции с голям обем или множество складове. Подробни описания и изображения често могат да се публикуват по график или след одобрение. Ценообразуването може да е в реално време за договорни сметки, докато публичните обявени цени могат да се актуализират за една нощ.

Проектирайте интеграцията, като вземете предвид бизнес последиците от остарели данни. След това включете предпазни мерки: уникални идентификатори, които се запазват в различните системи, картографиране на ниво поле, обработка на повторни опити, регистрационни файлове за грешки, отчети за съгласуване и предупреждения за неуспешни актуализации. Екипите трябва да могат бързо да отговарят на прости въпроси: Кои продукти не са успели да се публикуват? Кое поле е причинило неуспеха? Достигнал ли е коригираният запис до магазина?

За сложни каталози е полезно също така да се отделят суровите данни за доставчици от одобрените данни за публикуване. Информационните канали за доставчици могат да се приемат автоматично, да се съпоставят с вашия вътрешен модел и да се маркират за преглед. Това предотвратява незабавната промяна на непроверен доставчик в активен списък или спецификация, насочена към клиента.

Установяване на управление, което хората могат да следват

Технологията не може да реши неясните процеси на одобрение. Централизацията на данни за продукти се нуждае от практическо управление: кой може да редактира информацията, какво изисква одобрение и какво се случва, когато е необходимо изключение.

Достъпът, базиран на роли, помага за разделяне на отговорностите. Купувачите могат да актуализират полетата за доставчици и снабдяване. Специалистите по продукти могат да управляват спецификациите и съвместимостта. Маркетингът може да обогати текстовете и медиите. Мениджърите по продажбите могат да одобряват видимостта на B2B асортимента. Интеграциите могат да актуализират наличността и изчислената наличност, без да позволяват на потребителя случайно да презапише тези оперативни стойности.

Създайте правила за публикуване, които отговарят на търговския риск. Нова SKU може да изисква присвояване на категория, описание, изображения, размери и данъчен код, преди да може да се появи онлайн. Резервна част може да се нуждае от връзка „съвместимо оборудване“, преди да може да бъде поръчана. Промяна на цената над определен праг може да изисква одобрение преди публикуване.

Управлението трябва да бъде твърдо, но не и обременяващо. Ако дадено правило създава ненужно забавяне за актуализации с нисък риск, персоналът ще го заобиколи. Най-добрите работни процеси правят правилните действия по-лесни от изпращането на електронна таблица по имейл.

Внедряване на етапи, а не еднократно преминаване към целия каталог

Повечето проекти за продуктови данни трябва да започват с представителна категория, а не с целия каталог. Изберете продукти, които разкриват реална сложност: варианти, технически атрибути, множество ценови групи, медийни активи и инвентар от повече от едно място. Една проста категория може да направи внедряването да изглежда успешно, без да се тестват важните правила.

Почистете и премахнете дублиранията на тези начални данни, установете собствеността на полетата, изградете съпоставянията и изпълнете интеграцията паралелно със съществуващите процеси. Сравнете записи в различните системи. Тествайте създаване на артикул, промяна в инвентара, актуализация на цената, спрян от производство продукт и изключение, причинено от непълни данни.

След като работният процес се стабилизира, разширете го по категории или канали. Измерете резултатите в оперативни термини: време за пускане на продукта на пазара, процент на завършени записи на продукти, процент на неуспешна синхронизация, анулирания на поръчки, причинени от грешки в данните, и обем на ръчните корекции в каталога. Тези показатели показват дали новата архитектура подобрява бизнеса, а не просто премества информацията на нов екран.

Добре проектираната база данни за продукти дава на екипите пространство за растеж, без да превръща всяка нова SKU в системен проект. Започнете с полетата и работните процеси, които създават най-големи трудности, направете собствеността изрична и изградете интеграции, които могат да бъдат наблюдавани и надеждни. Каталогът ще стане по-лесен за управление, но по-голямото предимство е търговска операция, която може да действа въз основа на точна информация, когато е от значение.