Сеть GS1 TSD обещает снабдить потребителей надежными сведениями о приобретаемых товарах. И сулит прекрасное будущее. Но какие «побочные», не предусмотренные разработчиками нюансы и тонкие моменты могут таиться в глубинах фреймворка TSD? Интересы всех ли участников данного проекта учтены в полной мере?

В рамках проекта GS1 TSD (Trusted Source of Data) планируется предоставить технологическую основу для коммуникаций всех, кто производит и потребляет товары, относящиеся к FMCG и т.п. Новизна проекта в том, что «право голоса», впервые в истории EDI, будет дано конечным потребителям.

Стейкхолдерами проекта GS1 TSD , помимо производителей, являются и торговые сети. По крайней мере, это справедливо в той его части, где речь заходит про торговые марки самих ритейлеров или, — если назвать их по-другому, — СТМ.

Однако рост прямых коммуникаций покупателей и производителей, катализатором которых со временем станет TSD, может вызвать «побочные» эффекты. Ведь приучив потребителя к тому, чтобы получать надежные и полезные ему, — в процессе принятия покупательских решений, — сведения из сети, следует ожидать и того, что со временем он начнет пытаться получить не только сведения, но и сам товар тоже. Действуя при этом примерно тем же способом.

Данные изменения в потребительском поведении могут оказаться невыгодными для «классических» ритейлеров, не успевших пока еще обзавестись интернет-магазинами в дополнение к своему основному розничному бизнесу. Зато рост сетевой активности населения пойдет на руку сегменту e-commerce. Особого упора на интернет-магазины GS1 сейчас не делает. Хотя не исключено, что в его документах под участниками TSD с наименованием Internet Application Providers (IAPs) неявно подразумеваются и скрываются, — до поры до времени, — и они тоже. Ведь софт для интернет-магазина можно назвать своего рода приложением. В каком-то смысле этого слова.

Стоит напомнить, что под потребителями в рознице многие понимают как покупателей, так и ритейлеров. Может быть поэтому в документах TSD пока так и не прозвучала отчетливо и акцентированно изложенная тема аутсорсинга.

В частности, не отмечена там давно назревшая во многих странах тема универсального сервиса, позволяющего ритейлерам получать извне стандартные и абсолютно корректно заполенные карточки с описанием товара. Делая это простым способом — вроде клика мыши.

Кроме того, неизвестно, кто воспользуется таким «карточным» сервисом первым. Это будет обычный ритейлер? Или же его конкурент — крупный интернет-магазин? Который начнет «уводить» потребителей, пользуясь тем, что он может назначить более низкие цены за счет отсутствия издержек на содержание магазинов и многочисленного торгового персонала.

Хотя, конечно, всевозможным future stores, ищущим дополнительных «оправданий» необходимости наличия покупательских смартфонов в торговом зале, тема новых источников предварительно очищенных данных для потребительских мобильных приложений будет весьма интересна. Вот только жаль, что погоду на рынке они пока не делают. Хотя и быстро растут. Поэтому их так и называют — future stores, «магазины будущего».

Из теоретического наличия спроса на сервисы TSD в инновационных форматах ритейла, не следует, что он подкреплен деньгами. На жаргоне продажников, покупателей, которые приходят в магазин для того, чтобы только посмотреть товар, но не для того, чтобы его купить, иногда называют «гостями из будущего». На них не тратят особых сил ни опытные продавцы-консультанты в торговом зале. Ни GS1 с его TSD.

В любом случае, основные обязанности по наполнению TSD достоверными данными возложены сегодня на держателей всевозможных торговых марок. Чтобы попасть в TSD, они могут воспользоваться сетью GDSN. Также для них будут предоставлены возможности загрузить данные через веб-портал или же напрямую из ERP. Или через сервисы агрегаторов, которые примут у них EDI-сообщения, текстовые файлы, файлы в формате Excel, XML и т.д. Допускается воспользоваться услугами сторонних авторизованных провайдеров.

Если попытаться обобщить, то чинить преград никто не собирается. И все пути, ведущие в TSD, для вендоров будут открыты. По крайней мере — в теории. Лишь бы они захотели, так сказать, по ним пройти.

Впрочем, нельзя не заметить и того, что владельцам торговых марок, наполняющих базы агрегаторов TSD своими данными, мягко, но весьма настоятельно рекомендуется также стать и пользователями сети GDSN. О росте популярности которой в России мы сказать здесь пока ничего нового и содержательного вам не можем.

Соответственно, если производители согласятся с этим ненавязчивым предложением, то им придется также пройти и авторизацию в GDSN Source Data Pool (SDP). GDSN, поэтому, можно назвать магистральным (хотя и не единственным) путем для данных, желающих попасть в TSD. Остается добавить, — все это, почти что гарантированно, пойдет на пользу развития, прежде всего, самой сети GDSN. Даже если дело с TSD вдруг, по любой причине, застопорится. Чтобы завершить что-то старое, нужно начать что-то новое. Чисто внешне выглядит все это как-то так. В любом случае, «сетевая» преемственность налицо.

Что именно, произойдет внутри TSD , в конечном итоге, с данными, полученными от тех, кто упорно не подключатся к GDSN (или, на худой конец, не заключает соглашение со сторонним провайдером, уже имеющим такого рода договор на руках), на самом-то деле, предположить сейчас сложно. Не исключено, что они надолго «застрянут» где-то в промежутке между провайдерами и агрегаторами.

Для тех, кто подобно нам, ленится изучить очередной многостраничный отчет GS1, пытаясь там отыскать ответы на подобные вопросы, будет гораздо проще, если договор с GDSN взять, да и подписать. Заметьте, что никто при этом никого не заставляет это делать. Дело сугубо добровольное. А мы — просто делимся субъективными впечатлениями от прочитанного. И даем вам дружеский совет: будет проще подключиться, чем до конца все дочитать.

Некой прерогативой агрегаторов TSD является синхронизация данных, собранных изо всех заслуживающих доверия источников. Если бы не данное обстоятельство, то агрегатор стал бы, пожалуй, неким лишним звеном, своего рода транзитным шлюзом. Основной задачей которого стало бы безошибочно увязывать товар, идентифицируемый по GTIN, с его атрибутами, «подцепленными» по индексу.

Для целостности картины, добавим, что агрегаторы могут получать данные и от сторонних провайдеров контента (3rd party content providers). К которым, например, относятся маркетинговые агенства, организации-участники GS1, предоставляющие сервисы каталогов, а также заводы-производители СТМ для ритейлеров и пр.

Все их объединяет одно — товарным брендом они не владеют. Поэтому условием, при котором сторонние операторы смогут пополнять своим контентом распределенную, синхронизированную базу TSD, является наличие у них авторизации, полученной от зарегистрированных владельцев бренда. Получается, что одной из задач агрегаторов является обеспечение достоверности данных. Каким бы путем, через чьи руки они бы ни «пришли» в TSD, надежным их первоисточником всегда должен быть держатель бренда. Который, по определению, должен знать о своем продукте абсолютно все.

Таким образом, провайдеры, наполняющие контентом приложения для конечных потребителей, могут быть вполне уверены, что все данные, взятые из TSD, получены «от чистого истока» — непосредственно от владельцев товарных марок. Если же они захотят дополнить данный вид контента какими-то другими, самостоятельно собранными сведениями, то предоставлять эту дополнительную информацию пользователям они должны так, чтобы не «смешивать» (в представлении покупателей) надежные и проверенные данные из TSD со всеми прочими.

Можно предположить, что речь идет о четком разделении, — в рамках мобильных и прочих приложений для покупателей, — т.н. карточки товара с ее «вендорским» описанием. И «всего остального», типа (субъективных) отзывов пользователей, которым, скажем, понравился или не понравился данный товар. В этом месте следует еще раз напомнить себе о том, что налаживание такого рода двусторонних коммуникаций изготовителей с конечными потребителями является одной из важных  задач, которую призвана решить сеть TSD. Хотя бы потому, что других поводов вспомнить об этом обстоятельстве в документах GS1 мы пока не нашли.

Впрочем, понятно, что список атрибутов подлежит расширению с течением времени. Ибо информации, допустим, о количестве содержащегося в продукте витамина С, явно недостаточно для того, чтобы вполне удовлетворить современного потребителя. А на начальных стадиях проекта, ничего существенно иного, чего бы уже не было в той же GDSN, отыскать в глубинах TSD не удастся.

На первой фазе проекта TSD будет отработан процесс предоставления лишь только базовых сведений о составе продуктов питания, в т.ч. напитков

Источник: GS1, Trusted Source of Data Project Report (July 2012)

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

Приведем пример. Допустим, мы хотим ввести в сеть данные об одежде. Базовых сведений о том, что, допустим, рубашка сделана их хлопка и имеет белый цвет может оказаться недостаточно для того, чтобы предоставить привередливому современному покупателю всю информацию, которая ему необходима (Рассчитана ли сорочка на то, чтобы носить ее с костюмом? Годится ли форма воротничка для фрака? Как быстро рубашка мнется при носке? И т.д.).

Возможно, что основные тяготы по поиску «кандидатов» среди атрибутов, пригодных к тому, чтобы включить их в стандартную карточку с описанием потребительских свойств товара, будут, в конечном итоге, так или иначе, но, все таки, возложены на провайдеров приложений. Или, — по другому, на IAPs, — если придерживаться терминологии TSD. По крайней мере, если они не осилят пачку документов с описанием TSD и не найдут там убедительных мотивов для отказа, то, скорее всего, им придется приступить к таким поискам.

Строить предположения о том, насколько далеко продвинется TSD в деле налаживания двухсторонних коммуникаций по поводу актуальных потребителям свойств товара, можно очень долго. Проще будет посмотреть, как и в каком именно направлении будет развиваться данный проект GS1, — а не описывающие его документы, — на практике.

Пока же проект TSD сконцентрирован, в первую очередь, на пищевом фасованном скоропорте и напитках. Состав базовых признаков товара довольно-таки жестко ограничен описанием их состава. Фактически, речь сегодня идет лишь о том, чтобы рассказать потребителю про то, что и так «лежит на поверхности» (написано на этикетке), проще всего поддается структуризации в рамках стандартов. И может быть особо интересно потребителям, пекущимся о своем здоровье.

«Все остальное» тоже уже возможно. Но пока, скорее, лишь на уровне факультатива. В общем же, главная цель проекта TSD благая: ведь, действительно, давно уже нужно научиться выслушивать мнение конечного потребителя и доводить до покупателя полную и достоверную информацию о товаре в удобном ему «электронном» формате. Хотя, вполне может быть, что слово «полную» лучше было бы заменить на «релевантную». А то как бы из изначально благих намерений, в итоге, не получилось бы чего-нибудь, вплотную примыкающее к темам типа гринвошинга. Или же структурирования той информации, которая не особо-то интересна потребителям. И прочим, внешне красиво обставленным, — и вполне комфортным, — поискам «под фонарем», ведущихся там, где лучше видно, а не там, где следует искать на самом деле.

Вернемся к документам. Примечательно, что сторонние провайдеры контента тоже должны синхронизировать свои данные с агрегаторами. Очевидно — с теми, с которыми уже подписан договор и налажен обмен. Однако описания того, что будет, если держатель бренда предоставит обновление данных агрегатору и стороннему провайдеру с задержкой по времени, нам пока что отыскать не удалось.

Хотя очевидно, что в этом случае может возникнуть расхождение в данных об одном и том же товаре. Ведь в рамках TSD, пожалуй, почти невозможно строго обязать владельца бренда предоставлять любые изменения и дополнения, в первую очередь, агрегатору. А не, допустим, работающему с изготовителем товаров маркетинговому агентству. Для разрешения такого рода коллизии одной только отметкой о времени поступления информации отделаться не удастся.

В пространном, но достаточно общем описании фреймворка, где оперируют выражениями типа «разумное требующееся время» (или «reasonable performance times»), четкие ответы на такие вопросы обнаружить нам пока не удалось. Может быть, в них предполагается, что у изготовителя даже мысли о том, чтобы поделиться свежей информацией с кем-то еще, возникнуть не может? И он должен немедленно сообщать о любом малейшем изменении в своих спецификациях прямиком в TSD?

Таким образом, вовсе не исключено, что всех участников TSD, постараются незаметно «подзагрузить» на полу-общественных началах различными обязательствами и функциями, которые раньше пытались, — как-то более централизованно, — загнать в рамки GDSN.  Так это будет на самом деле или нет — покажет время.