Почему нельзя просто взять и внедрить PIM-систему?

Кажется, внедрение PIM-системы — задача предельно простая, даже если раньше компания работала без неё. Есть справочники, потоки — чего же ещё нужно? Бери и делай, осталось только выбрать «правильную» систему!

Действительно, продукты — более-менее освоенная область исследования. Компания постоянно работает с номенклатурой — вряд ли здесь может иметь место нехватка какой-либо информации. В Dropbox лежат XLS-файлы, ещё часть информации хранится в «1С» и на сайте. Осталось лишь объединить данные и сложить их в одном месте.

Но это ловушка. Скорее всего, если «просто взять и внедрить», уже через пару месяцев придётся приступать к полной переработке PIM-системы, поскольку выяснится, что в карточке товара не учтён какой-то нюанс, свойственный продуктовой категории, в жизненном цикле товара — редко встречающийся сценарий, а в структуре атрибутов — требования половины отделов, участвующих в обеспечении этого самого жизненного цикла.

Компания KT.Team интегрировала PIM-системы в IT-архитектуру более 25 компаний — торговых, производственных, сельскохозяйственных и даже сервисных. Опираясь на полученный опыт, мы разработали собственный внутренний регламент внедрения PIM-систем, состоящий из семи этапов.

В данной статье мы поделимся с вами этим регламентом и расскажем, каких ошибок во внедрении PIM-системы позволяет избежать каждый из описанных этапов.

Коротко о PIM-системах

Сколько параметров у вашего продукта (услуги)? Согласно некоторым исследованиям, для базового описания продукта требуется до 200 параметров, а иногда и больше: габариты, масса в упаковке и без неё, цвет, размер (например, одежды), основной и дополнительный материалы, параметры производства, сезонность, мощность, функции, комплектация… Полный список настолько длинен, что его можно смело выносить в отдельную статью.

Обычно вся эта информация хранится в компании разрозненно. Что-то находится в ERP, что-то — в табличках на стационарных компьютерах или в облаках. Фото продукта и сертификаты — в сетевых хранилищах. Данные для аналитики — в BI-системе, сезонность — в головах сотрудников отдела продаж…

И когда требуется собрать имеющиеся сведения воедино (например, чтобы приступить к работе с новым дилером на новом для себя рынке), целый отдел тратит несколько дней на сбор, актуализацию и перепроверку данных — таков реальный кейс одного из клиентов KT.Team, но, полагаем, с подобной ситуацией сталкивались многие.

PIM-система (сокр. от англ. product information management system) — это мастер-система хранения информации о товарах и услугах. В PIM-системе можно хранить текстовую информацию, вычисляемые параметры, медиафайлы, данные для аналитики, атрибуты, региональные и сезонные признаки, цены и т. д. Если возникает необходимость выгрузки всех данных на новый маркетплейс или передачи их дилеру, такой процесс занимает лишь несколько минут вместо нескольких дней.

Ещё один плюс PIM-системы — функционирование в качестве единого источника информации о товарах. Больше не возникают досадные ситуации, когда один дилер описывает цвет корпуса пылесоса как «тёмно-серый», второй — как «серый», третий — как «чёрный», а покупатель не понимает, кому верить, и переносит негатив на производителя пылесоса.

PIM-система «раздаёт» информацию на все каналы продаж: на портал дилеров, маркетплейсы, торговые точки, интернет-магазины, печатные каталоги и др. Можно задать единую структуру описания и комбинацию полей для всех каналов или, наоборот, настроить специфичную модель выгрузки для каждого из них.

Пользоваться PIM-системой могут одновременно все подразделения компании, чья деятельность так или иначе связана с обеспечением жизненного цикла продукта: производство, закупки, продажи, маркетинг, логистика и т. д. Настраиваемые роли и уровни доступа (предусмотренные в большинстве PIM-систем) позволяют каждому подразделению получать доступ только к той части информации, которая важна для него или находится в зоне его ответственности.

Наконец, в PIM-системах предусмотрен механизм контроля качества и полноты публикуемой информации. Если для вас важно, чтобы на каналах продаж появлялись товары не менее чем с тремя фотографиями, PIM-система не пропустит к публикации карточки товаров без фото. Или другой пример: если масса шкафа не может быть меньше 15 кг, PIM-система не валидирует карточки шкафов массой 3 кг.

Но есть нюанс: PIM-система сама по себе не станет «серебряной пулей» для всех проблем и задач по работе с данными о товарах — для этого её нужно правильно внедрить.

Семь шагов на пути к правильному внедрению PIM-системы

1. Зафиксировать проблему, которую планируется решить внедрением PIM

Как правило, основная проблема с данными обнаруживается задолго до появления задачи на внедрение PIM. Беспорядок в данных, сложности со сбором информации, разрозненность — так бизнес-заказчики чаще всего формулируют свои проблемы на старте.

Не имея предыдущего опыта работы с PIM-системами, можно остановиться и на этих вводных. Но подобная стратегия опасна — в первую очередь для заказчика.

Зачастую к интегратору обращается только тот отдел, что заинтересован во внедрении PIM, — обычно это e-commerce-подразделение, коммерческий отдел, отдел продаж производственного предприятия. Однако данными о продуктах, как правило, пользуются одновременно несколько подразделений. Например, у нашего клиента, торгово-производственной компании «Аскона», среди таких подразделений — закупки, производство, складское хозяйство, логистика, продажи, e-commerce, маркетинг и т. д. Жизненный цикл продукта неотсекаем от основного бизнес-процесса.

Если при внедрении PIM не учитывать потребности всех отделов, пользующихся информацией о товарах, формирующих или изменяющих её, в конечном счёте компания получит нерабочий инструмент — будет нарушена сервисная модель.

Здесь внимательный читатель возразит: можно же запустить MVP для одного отдела, а потом доработать! Например, сейчас перенести в PIM лишь информацию с сайта, а поля для маркетплейсов, логистики и производства добавить в следующих итерациях.

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

Вы готовы отдавать миллионы, чтобы ничего принципиально не изменилось (а то и ухудшилось, добавив бардака в данных)?

Поэтому первый шаг внедрения — сбор жалоб и запросов всех подразделений, как-либо взаимодействующих с информацией о товарах. Уточнение деталей займёт у команды внедрения какое-то время. Нужно будет составить схему сервисов предприятия, понять, как надлежит реорганизовать контур, и согласовать предлагаемые изменения со всеми заинтересованными отделами.

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

2. Спроектировать и согласовать информационные модели

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

На этой стадии внедрения важно отказаться от убеждения «если мы всегда так делали, значит, надо перенести прежний опыт и на PIM». Придётся «пересобрать» работу с информацией о товарах, задав правильные вопросы о том, что важно и нужно каждому из отделов.

• ‍Есть ли расхождения в понимании терминов между отделами? Все ли понятия воспринимаются заинтересованными отделами одинаково? Если нет — в чём различие и что важно учитывать?
  ‍Например, одна из компаний, с которой мы работали, хранила оптовые и розничные артикулы в одном месте. При этом отдел закупок и отдел розницы понимали под «артикулом» разные сущности.
  Так, для закупок одинаковые артикулы могли означать разные цвета одного и того же товара, но сам товар должен был быть произведён на одном заводе.
  Для розницы, наоборот, не было важно, на каком заводе произведён товар, а вот цвет имел принципиальное значение. Кроме того, существовали нюансы в части оптовой и розничной упаковки.
  Ни о чём подобном до начала внедрения компания не заявляла, поскольку такое расхождение в терминологии было давним и само собой разумеющимся. Конфликты обнаруживались лишь при внимательном разборе данных о товарах, т. е. когда мы сталкивались с конфликтами данных напрямую. В конце концов пришлось перестраивать информационные модели с учётом позиции обоих заинтересованных отделов.
  Представьте, если бы PIM-система внедрялась только по запросам розницы, хотя пользоваться ею планировали и закупки. В каком положении по итогу оказались бы последние?

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

‍

А так выглядит информационная модель подушки в PIM-системе. И это только половина характеристик!

В информационной модели учтены все характеристики, важные для продаж, маркетинга, производства, логистики, закупок. Подушка — это не просто «50 × 70 см, наполнитель — овечья шерсть». Карточка товара должна отвечать на сотни вопросов:
- Каковы характеристики упаковки: размеры, материал?
- Каковы особенности производства: строчка, ткань чехла, замок, количество слоёв чехла и наполнителя?
- Для кого предназначена эта подушка? Для любителей спать на мягком или на жёстком? На спине, на боку или сидя? Подходит ли она людям с остеохондрозом?
- Пропускает ли подушка воздух? (Да, есть и такая характеристика!)
- В каких каналах продаётся подушка: в собственных магазинах, на маркетплейсах? А может, эта модель продаётся исключительно в B2B-сегменте — отелям?
Эта информация собиралась и хранилась всегда, однако до внедрения PIM-системы хранили её нецентрализованно в нескольких системах, Excel-файлах и методичках. Чтобы учесть и собрать все важные сведения в одну «золотую запись», нужно изучить каждую категорию товаров.
‍

• Как на самом деле устроены неосновные процессы и какие атрибуты с ними связаны?
  ‍Заказчик PIM-системы (основной отдел, выступивший с инициативой по поводу внедрения) не всегда знает, как устроена работа с информацией о товарах в других отделах, и потому не может предоставить достоверные сведения обо всех нюансах этой работы.
  Например, одна крупная компания, которая получала продукты от другого предприятия в холдинге, утверждала, что все атрибуты порождаются внутри холдинга и подлежат управлению. Когда мы стали анализировать роли и информационные модели, у нас возникло подозрение, что такое просто невозможно: данные были чрезвычайно разрозненными, их ведение требовало бы слишком больших трудозатрат.
  В результате многочисленных переговоров удалось выяснить: две трети атрибутов загружаются напрямую от заводов-поставщиков и далее никак не обрабатываются внутри холдинга, т. е. их не надо ни вводить, ни изменять — достаточно лишь импортировать.
  Если бы мы внедрили PIM, опираясь только на первый комментарий заказчика, информационная модель карточки товара была бы более сложной и по архитектуре, и по эксплуатационным свойствам.
  Бывали и обратные случаи, когда информационные модели некоторых категорий оказывались подозрительно простыми. После подробного разбора и уточнения выяснялось, что на самом деле «проблемных зон» было много, но разобрался с ними всего один отдел за счёт собственных внутренних процессов, а другим департаментам была видна лишь «простая модель».

Если подобные скрытые процессы оставить без внимания, самые перегруженные отделы не получат от PIM-системы ожидаемого эффекта. Будет копиться недовольство от нового продукта. А со временем назреет запрос «выйти и войти нормально» — перевнедрить PIM, но теперь уже так, чтобы всем было удобно.

Важно понимать, что, скорее всего, ваша команда знает о процессах не всё, и для построения нормальной информационной модели продукта придётся задать ещё сотни вопросов.

3. Определить, что не требует проработки

Исходя из содержания предыдущего пункта, можно представить, какими трудозатратами обойдётся проработка информационных моделей со всеми переговорами, переписками, уточнениями и вопросами. Минимум — 40 часов. А если категорий 20 или 50?.. Только проработка информационных моделей займёт у бизнес-аналитика год рабочего времени.

Да, но…

На старте необходимо понять, все ли категории действительно являются уникальными и требуют отдельной проработки — возможно, информационные модели некоторых товарных категорий неуникальны.

Например, в каталоге нашего клиента — производственной компании — 53 товарные категории. Но с точки зрения работы информационной модели только 30 из них уникальны — в результате общее время на проработку сократилось на 920 часов (23 × 40)!

У другого нашего клиента, оптового поставщика электротехнического оборудования, в активном каталоге восемь категорий: «Кабели и провода», «Электротехническое оборудование», «Светотехническое оборудование», «Кабеленесущие системы», «Материалы для монтажа», «Электрощитовое оборудование», «СКС и телеком», «Инструменты и средства защиты».

Казалось бы, нужно разработать восемь информационных моделей товаров… Но изучение структуры информации о товарах показало, что фактически достаточно лишь двух универсальных моделей: для кабелей и для остальной электротехнической продукции. Таким образом удалось сократить время, ушедшее на разработку при внедрении PIM-системы, а также снизить трудозатраты после внедрения примерно на 20 %.

4. Зафиксировать роли и уровни доступа к карточкам товаров

В предыдущих пунктах мы неоднократно говорили о том, что работа с информацией о товаре часто не локализована в одном подразделении, а распределена между несколькими. Каждый из отделов вносит свою часть информации, причём внутри отделов также существуют различные роли. Например, ТИмофей (все совпадения случайны) получает от отдела закупок Excel-файл и известным только ему способом разносит информацию оттуда, скажем, в ERP, а часть информации вносят поставщики.

Сложившееся неявное разделение на роли нужно оцифровать, настроив уровни доступа для разных ролей: что могут менять категорийные менеджеры, кураторы, поставщики, маркетологи, кто будет согласовывать изменения, какие триггеры будут срабатывать… И тут мы переходим к следующему пункту — оцифровке бизнес-процессов работы с информацией о товаре.

5. Описать жизненный цикл информации о товаре в виде бизнес-процесса

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

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

Как бы силён ни был соблазн, остановиться на такой схеме не получится. После наложения ролевой модели, условий, атрибутов и уникальных кейсов схема обычно приобретает следующий вид.

Заметная разница, правда?

Здесь читатель может возразить, что настолько детально выстроенные бизнес-процессы лишь увеличивают общее время внедрения PIM-системы, а потому строить их не обязательно. Фактически это не более чем оцифровка существующего положения вещей.

И да, и нет. Если у вас нет чётко выстроенных процессов с ясно обозначенными статусами, ответственными сотрудниками, входами и выходами — могут возникать трудности с пониманием того, всё ли идёт нормально, нужно ли что-то менять и как именно это делать.

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

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

6. Решить, каким образом будет реализована интеграция PIM с другими системами

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

Хорошо, если так. Но на практике, как вы знаете, зачастую что-то работает не так, как ожидалось, вынуждая искать обходные пути: создавать маппинг между источником информации (например, порталом поставщика) и PIM-системой, связывая атрибуты для корректной загрузки, настраивать выгрузки так, чтобы они не дублировались, и т. д.

Со своей стороны мы рекомендуем строить интеграции не в парадигме «точка – точка», а через ESB-слой: такой подход снимает с конечных систем, в том числе с PIM, несвойственные им функции, уменьшает объём кода и делает интеграции более управляемыми. Подробнее о ESB-системах можно почитать в этой статье.

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

Проработать, настроить, согласовать, перестроить… полностью переработать?

«Постойте, — скажете вы, — что значит „переработать“? Получается, даже если пройти все шесть предыдущих этапов, всё равно придётся вносить изменения в PIM-систему?»

Можем сказать по своему опыту — да, придётся. Где-то минорно, а где-то потребуется переосмыслить большой блок информации.

Проведение предпроектной аналитики позволяет приблизиться к оптимальному варианту PIM-системы на момент внедрения и избежать создания заведомо нерабочего проекта. Но IT-контур не может (не должен) замирать на века. Ваша компания развивается как живой организм: меняются бизнес-процессы, модели взаимодействия, бизнес в целом. А поскольку IT-контур и каждый из IT-сервисов всегда должны быть отражением бизнеса, неизбежно придётся менять и их.

И здесь есть важное соображение: надеяться, что удастся «подкопить минорные правки и вернуться к интегратору через год», не стоит. Как только система перестанет обеспечивать текущие процессы за счёт собственных функций, ваши сотрудники снова привыкнут решать свои задачи в обход PIM — с помощью Excel, «1С», «Google Таблиц»… И к моменту вашего повторного обращения к интегратору PIM уже превратится в неиспользуемое обременение. Поэтому тактика накопления и откладывания приведёт лишь к необходимости перевнедрения PIM-системы вместо планировавшегося внесения минорных доработок.

Между системой, которая сделана «разово» и не способна к изменениям, и системой, которая постоянно модифицируется, гибко подстраиваясь под актуальные потребности бизнеса, — гигантская пропасть в разрезе ценности для бизнеса. И имя этой пропасти — бережливость и непрерывное совершенствование (а ещё Agile и цифровая трансформация). Если не думать о ней, то и внедрять PIM не стоит — Excel будет лучше.

‍