Итак, на первом этапе команда внедрения зафиксировала существующие проблемы и ожидания от PIM-системы, озвученные различными подразделениями компании. Следующий шаг — построить такую информационную модель карточки товара (или несколько информационных моделей), которая будет учитывать все обозначенные интересы.
На этой стадии внедрения важно отказаться от убеждения «если мы всегда так делали, значит, надо перенести прежний опыт и на PIM».
Придётся «пересобрать» работу с информацией о товарах, задав правильные вопросы о том, что важно и нужно каждому из отделов.
Есть ли расхождения в понимании терминов между отделами?
Все ли понятия воспринимаются заинтересованными отделами одинаково?
Если нет — в чём различие и что важно учитывать? Например, одна из компаний, с которой мы работали, хранила оптовые и розничные артикулы в одном месте.
При этом отдел закупок и отдел розницы понимали под «артикулом» разные сущности. Так, для закупок одинаковые артикулы могли означать разные цвета одного и того же товара, но сам товар должен был быть произведён на одном заводе.
Для розницы, наоборот, не было важно, на каком заводе произведён товар, а вот цвет имел принципиальное значение.
Кроме того, существовали нюансы в части оптовой и розничной упаковки.
Ни о чём подобном до начала внедрения компания не заявляла, поскольку такое расхождение в терминологии было давним и само собой разумеющимся.
Конфликты обнаруживались лишь при внимательном разборе данных о товарах, т. е. когда мы сталкивались с конфликтами данных напрямую. В конце концов пришлось перестраивать информационные модели с учётом позиции обоих заинтересованных отделов. Представьте, если бы PIM-система внедрялась только по запросам розницы, хотя пользоваться ею планировали и закупки. В каком положении по итогу оказались бы последние?
Каковы правила взаимосвязи и ограничений?
Этот вопрос особенно важен для производственных компаний, хотя иногда с ним сталкиваются и торговые предприятия.
Такие взаимосвязи часто не учитываются в явном виде, т. к. «все, кому надо, о них знают».
Например, если дверца шкафа длиннее 170 см, она крепится на три петли.
Или если каркас дивана выполнен из МДФ, цветовая гамма ограничена пятью цветами, а если из дерева — семью.
Есть и менее очевидные правила: вместо списка атрибутов — некий диапазон с правилом выбора значений. Скажем, длина и ширина изделия могут находиться в промежутке от 80 до 260 см с интервалом 1 см, однако при ширине менее 120 см длина не может превышать 160 см.
Такие правила и взаимозависимости можно не учитывать при настройке информационных моделей.
Но в этом случае внедрение PIM-системы превращается в «перекладывание табличек»
из Excel в PIM, что в системном отношении не решает никаких проблем: сотрудники будут и дальше заполнять бесконечные карточки, просто теперь — в новой системе.
Какие данные о товаре нужно формализовать в карточке товара?
Создание цифровой копии товара подразумевает формализацию огромного объёма информации.
Посмотрим на обычный незамысловатый товар — подушку.
Так она выглядит на маркетплейсе. Кажется, ничего сложного? А так выглядит информационная модель подушки в PIM-системе. И это только половина характеристик!
В информационной модели учтены все характеристики, важные для продаж, маркетинга, производства, логистики, закупок. Подушка — это не просто «50 × 70 см, наполнитель — овечья шерсть».
Карточка товара должна отвечать на сотни вопросов: -
Каковы характеристики упаковки: размеры, материал? -
Каковы особенности производства: строчка, ткань чехла, замок, количество слоёв чехла и наполнителя? -
Для кого предназначена эта подушка?
Для любителей спать на мягком или на жёстком?
Подходит ли она людям с остеохондрозом? -
Пропускает ли подушка воздух? (Да, есть и такая характеристика!) - В каких каналах продаётся подушка: в собственных магазинах, на маркетплейсах? А может, эта модель продаётся исключительно в B2B-сегменте — отелям?
Эта информация собиралась и хранилась всегда, однако до внедрения PIM-системы хранили её нецентрализованно в нескольких системах, Excel-файлах и методичках.
Чтобы учесть и собрать все важные сведения в одну «золотую запись», нужно изучить каждую категорию товаров.
Как на самом деле устроены неосновные процессы и какие атрибуты с ними связаны?
Заказчик PIM-системы (основной отдел, выступивший с инициативой по поводу внедрения) не всегда знает, как устроена работа с информацией о товарах в других отделах, и потому не может предоставить достоверные сведения обо всех нюансах этой работы. Например, одна крупная компания, которая получала продукты от другого предприятия в холдинге, утверждала, что все атрибуты порождаются внутри холдинга и подлежат управлению.
Когда мы стали анализировать роли и информационные модели, у нас возникло подозрение, что такое просто невозможно: данные были чрезвычайно разрозненными, их ведение требовало бы слишком больших трудозатрат. В результате многочисленных переговоров удалось выяснить: две трети атрибутов загружаются напрямую от заводов-поставщиков и далее никак не обрабатываются внутри холдинга, т. е. их не надо ни вводить, ни изменять — достаточно лишь импортировать.
Если бы мы внедрили PIM, опираясь только на первый комментарий заказчика, информационная модель карточки товара была бы более сложной и по архитектуре, и по эксплуатационным свойствам.
Бывали и обратные случаи, когда информационные модели некоторых категорий оказывались подозрительно простыми.
После подробного разбора и уточнения выяснялось, что на самом деле «проблемных зон» было много, но разобрался с ними всего один отдел за счёт собственных внутренних процессов, а другим департаментам была видна лишь «простая модель».
Если подобные скрытые процессы оставить без внимания, самые перегруженные отделы не получат от PIM-системы ожидаемого эффекта.
Будет копиться недовольство от нового продукта. А со временем назреет запрос «выйти и войти нормально»
— перевнедрить PIM, но теперь уже так, чтобы всем было удобно. Важно понимать, что, скорее всего, ваша команда знает о процессах не всё, и для построения нормальной информационной модели продукта придётся задать ещё сотни вопросов.
