«Аскона» — производитель и продавец матрасов, мебели и товаров для сна. Компания вкладывается в НИОКР, развивая «умный» подход к подбору товаров для сна — вплоть до анализа генетической предрасположенности к лучшему сну на более жёстких матрасах или высоких подушках. В результате каждый второй покупатель товаров для сна выбирает именно «Аскону» (бренд занимает 48 % рынка).

Только за 2020 год продажи по всем товарным группам увеличились на 10 % в розничных каналах, на 7 % — в B2B-каналах, на 62 % — через интернет-магазин. На 55 % выросло производство диванов и кроватей. Добавилось 80 новых ассортиментных позиций, у каждой из которых есть и собственные свойства, и модификации.

«Аскона» показывает хорошую динамику роста. Однако многие воркфлоу были разработаны и внедрены, когда ассортимент и масштабы производства «Асконы» были на порядок меньше, работал один завод (сейчас только в России их три). В тот момент большое количество «ручных» операций не было ограничением.

Вместе с развитием бизнеса нужно было менять и сами бизнес-процессы, и их представление в IT-системах.

При нынешних масштабах модернизация процессов стала насущной необходимостью. Поэтому в 2020 году «Аскона» решила автоматизировать планирование графиков работы, обработку документов в системе ЭДО, складскую логистику, работу с информацией о товарах и др. Изменения в процессах будут отражены и в обновлённом IT-контуре.

Например, для работы с информацией о товарах «Аскона» планировала внедрить PIM-систему. Чтобы сделать IT-архитектуру гибкой, легко масштабируемой и обновляемой компания решила использовать брокер сообщений.

С этими запросами компания обратилась в kt. team: так началось наше сотрудничество.

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

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

Поэтому внедрение началось с длительного этапа аналитики. Команда проектных менеджеров и аналитиков kt.team разбирала:

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

Раньше весь ассортимент «Асконы» состоял из материальных ценностей. Продавцы на офлайн-точке (а этих точек у компании только в России более 850) продавали, например, не кровать целиком, а отдельно две материальные ценности «каркас кровати» и «основание кровати»: так было удобно производству. Производство сразу получало заказы на соответствующие материальные ценности, разделённые по фабрикам и срокам поставки. При этом работа продавца усложнялась, процесс заказа был некомфортен и для покупателя.

Стандартный кейс:

Покупатель приходит в магазин и говорит: «хочу кровать X с подъёмным механизмом». Раньше продавцу надо мысленно «разложить» заказ на каркас и основание с подъёмным механизмом, уточнить, какие основания с выбранным каркасом совместимы (потому что могут быть нюансы), уточнить производственные сроки по каждой материальной ценности, снова «сложить» заказ. Покупателю приходилось ждать, пока все аспекты его заказа смогут уточнить, он не понимал, почему ему не могут сразу предложить «нормальную кровать».

Теперь продавец имеет дело с цельным товаром. Принимая заказ, он уже видит, в каких комбинациях доступна кровать X, есть ли среди них комбинации с подъёмными механизмами. Может рассказать, чем отличаются эти механизмы. Видит конкретные сроки производства не для каждой отдельной материальной ценности, а для кровати целиком.

Объединение материальных ценностей в товар удобно для продавцов и покупателей. Но для производства по-прежнему важно знать, какие материальные ценности нужны для комплектации заказа и из каких запчастей они будут состоять.

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

Один и тот же товар для разных подразделений «выглядит» по-разному. Например, обычная подушка:

Есть атрибуты, важные для закупок, для маркетинга, для отдельных каналов продаж и т. д.

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

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

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

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

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

Раньше процесс создания и заполнения карточки товара был полностью «ручным». Менеджерам приходилось вводить все параметры — а это иногда сотни значений — вручную в ERP-систему. Для отдельных типоразмеров одного и того же товара (например, матрас шириной 140 и 160 см) приходилось заводить отдельные карточки и дублировать ввод данных.

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

У «Асконы» достаточно широкий ассортимент — только в основном каталоге представлено 81 модель диванов и 362 модели кроватей (с учётом «базовых» размеров, тканей и наполнителей).

Реальные же производственные возможности намного шире. Модель теоретически можно изготовить в десятках тканей и нестандартных размеров, с разными наполнителями в спинках и разными вариантами подлокотников. Но у каждого из материалов есть ограничения: например, из ткани нельзя сделать широкие подлокотники, диван можно увеличивать только до определённой длины, ширина изголовья кровати должна быть кратна скольки-то сантиметрам…

На кастомизированные предметы приходится значительный процент продаж. Как был построен процесс работы с ними?

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

Пока в ассортименте было несколько базовых моделей, а общие продажи диванов оставались в пределах 100−200 штук в месяц, проблем не было — производство могло выделить время на просчёт 2−3 индивидуальных заказов в месяц.

На 2021 год «Аскона» производит в месяц 15 000 диванов, и производству приходилось проверять до 20 проектов ежедневно. «Очередь» к технологам растягивалась на две недели, а сами технологи были загружены большим объёмом необязательной работы!

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

Мы предложили альтернативное решение: все возможные опции и ограничения внести в справочники, а справочники «подключить» к карточке товара.

Теперь продавец показывает клиенту только те ткани, в которых можно изготовить понравившуюся модель, и проверяет все параметры прямо на POS-терминале в присутствии клиента. Если «идеальный вариант» невозможно выполнить с точностью до оттенка и миллиметра, продавец может предложить альтернативы клиенту здесь и сейчас.

Ощутимый результат на ноябрь 2021: уменьшение сроков согласования кастомизированных заказов. Есть основания предполагать, что в перспективе увеличится и количество успешных «нестандартных» заказов за счёт «обработки» клиента во время первого же визита.

Помимо товаров «Аскона» продаёт сопутствующие услуги: доставку мебели и товаров для сна, подъём на этаж, сборку и др. Эти услуги продавались отдельно по прайсам подрядчиков, которые их оказывают, и через отдельные договоры. Головному офису было сложно отслеживать статистику продаж по услугам и актуальность расценок на услуги на каждой из офлайн-точек.

Мы предложили завести услуги в PIM как отдельную категорию товаров. Тип услуги (например, доставка по городу) выступает в роли мастер-модели, которая, в свою очередь, может состоять из нескольких вариантов (доставка по Москве, по Санкт-Петербургу, по Хабаровску…). Каждому варианту соответствуют свои параметры и своя цена.

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

Например, клиент заказывает кровать с основанием и матрас к ней. Продавец сразу видит, что к такому набору товаров он может допродать доставку до подъезда. Покупатель живёт в многоэтажном доме? Значит, ему можно допродать подъём на нужный этаж. Клиент заказал доставку, а товар относится к тем, которые нужно собирать? Можно допродать ещё и сборку.

Товары и услуги группируются в один заказ. Продавец точно будет знать, что именно он продал конкретному покупателю.

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

Каждая позиция в ассортименте «Асконы» «окружена» многочисленными цифровыми активами: фотографии товара с разных ракурсов, 3D-рендеры, видео, сертификаты, награды, промо-материалы, инструкции по сборке и уходу и т. д. Дополнительно есть ещё массивы «общей» маркетинговой информации (например, по сезонным акциям), производственной информации, информации о сертификатах и лицензиях поставщиков «Асконы»… Это миллионы файлов.

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

Мы использовали DAM-возможности Pimcore. Все цифровые активы были перенесены в эту систему и упорядочены. Каждый цифровой актив привязан к соответствующим справочникам, продуктам. Найти нужный файл легко, а в карточку товара автоматически «подтягиваются» все нужные изображения.

Активы, которые имеют ограниченный срок действия, получили соответствующие отметки: при наступлении контрольной даты ответственный сотрудник получает уведомление о том, что пора продлять сертификат, обновлять фото на сайте или отключать рекламу (например, если истёк контракт со «звездой» или закончилась сезонная акция).

В 2020 году «Аскона» начала процесс глобального обновления IT-контура. Компания уже переросла масштабы, при которых можно было построить понятную и простую в управлении архитектуру с помощью point-to-point интеграций. Количество систем и интеграций превысило «критическую отметку», а курс на дальнейшее развитие IT заставил задуматься об альтернативных вариантах архитектуры.

Поэтому «Аскона» решила внедрить архитектуру с брокером сообщений в центре.

Исходя из этих требований был выбран брокер сообщений Kafka. Мы развернули брокер и интегрировали стандартный пользовательский интерфейс. Но это было только частью процесса. В общей сложности мы провели три лекции по разворачиванию Kafka и потратили более 100 часов на задачи по настройке и обслуживанию брокера.

В результате: