Кейс из Украины: перенос успешных практик из офлайна в онлайн на примере крупной сети обувных магазинов

Команда разработчиков AniArt о создании интернет-магазина для ритейлера Intertop.

Десять лет назад крупным ритейлерам с развитой сетью магазинов онлайн-продажи виделись модным приложением к реальному бизнесу. В 2016 году это уже не дань моде, а стратегическое направление развития. Поскольку если магазина нет в сети, то его и вовсе нет.

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

Мы выбрали к рассмотрению именно кейс по созданию интернет-магазина для сети Intertop, так как в нём было много вызовов: сделать быстро; объединить физические магазины и онлайн-площадку в единое пространство для клиентов сети, где им доступны все привычные возможности; перенести без потери качества весь маркетинговый комплекс из офлайна в онлайн.

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

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

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

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

Для того, чтобы онлайн-платформа стала самостоятельным каналом, её нужно полностью интегрировать с ERP-системой компании. Чтобы делать клиенту индивидуальные предложения, предлагать скидки и бонусы, необходима интеграция с CRM-системой, чтобы вся история взаимоотношений с клиентом была доступна онлайн: когда и какие покупки он делал, сколько накопил бонусных баллов, какими акциями он воспользовался и так далее.

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

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

В качестве платформы для интернет-магазина выбрали «Битрикс»: у нее открытая архитектура, довольно широкие встроенные возможности, а определенная гибкость системы дает свободу реализовывать нестандартную функциональность, требующуюся заказчику. Здесь приоритетными стали следующие вещи:

Что важно на этом этапе:

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

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

Простой индикатор того, что функциональность была хорошо реализована: уже в первый месяц работы магазина 25% покупок совершались с использованием бонусной карты Intertop Plus, которую клиенты регистрировали в личном кабинете.

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

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

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

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

Таким образом, в разработке нужно учитывать все эти риски, настроив систему так, чтобы этап «Оформление товара» работал в любых условиях.

На этом примере, кстати, интересно рассказать о дилемме по балансу автоматизации и ручного труда.

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

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

Заставлять клиента заполнять множество граф до тех пор, пока все они не будут заполнены правильно, — неудобно. Пытаться предугадать все возможные варианты написания и учесть их в разработке — дорого и неэффективно. В итоге пришли к компромиссу: пользователь вводит адрес так, как ему удобно, а потом менеджер в админ-панели этот адрес сам раскидывает по специальным графам. Это решение закрыло почти все жалобы с ТТН.

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

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

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

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

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

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

Именно он двигает бизнес, а внутри него «зашито» очень много нестандартной функциональности.

Intertop ведет очень активную маркетинговую политику. Одновременно может проходить до 20 акций, так что сами менеджеры могут перепутать, под какие акции подпадает тот или иной товар и как правильно применять к нему скидки.

Поэтому первое, что нужно было сделать, это доработать стандартную функциональность «Битрикс», которая не позволяет указывать особенные правила работы с корзиной и расчета скидок. Расскажем на примере. В компании есть четыре вида скидок:

Проблема в том, что все четыре скидки в «Битрикс» применялись одновременно, и расчет конечной цены получался некорректным. Нужно было изменить алгоритмы так, чтобы они рассчитывались в определенной последовательности: сначала применяется скидка на товар, потом списывается купон, бонусы и 5%.

Доработка потребовалась почти для всех популярных маркетинговых акций, например, акции «Купи три пары со скидкой 30% – 50% – 70%» или акции «Вторая цена», где сначала дается регулярная цена на товар, а потом вторая цена — по акции.

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

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

В итоге было найдено оптимальное решение: фактическое начисление бонусов на карточку стали проводить с небольшой отсрочкой после совершения покупки по акции. Почва для накруток исчезла.

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

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

Омниканальность, наверное, самый горячий тренд в электронной коммерции. Каждый второй интернет-магазин декларирует свое движение в сторону омниканальности. Что это такое? Приставка «омни» переводится как «существующий повсюду». На практике это означает следующее:

Например, можно из магазина в Одессе оформить доставку выбранной пары обуви в Днепропетровск, где клиент заберет ее в оговоренные сроки; можно зарезервировать какую-то пару в конкретном магазине и позже выкупить ее. Как показала практика, около 40% заказов онлайн — это резервы и пикапы.

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

Важно наблюдать за пользователями и всю доработку основывать на их поведении. Люди не разделяют каналы. Для них, что заказ на сайте, что приход в реальный магазин — это всё Intertop. И мы тоже должны убирать различия, делать так, чтобы обе площадки функционировали по единым правилам. За год работы интернет-магазина:

Например, как реализован процесс заказа: пользователь выбирает на сайте город, в котором он находится. Исходя из его местоположения, ему показываются товары с актуальными остатками по каждому размеру. При покупке он может выбрать опцию «Доставка в магазин» и указать любой магазин в любом городе.

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

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

Для крупной сети переход в онлайн критичен с точки зрения сохранения уровня сервиса и привычного для клиента имиджа бренда. Поэтому и задача здесь двухшаговая:

Благодаря этим шагам всего за три месяца Intertop получил большую лояльную аудиторию в онлайне.

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

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

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

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

Поэтому нашей первой задачей стал поиск консенсуса с заказчиком по двум вопросам:

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

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

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

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

В электронной торговле критически важной является способность системы выдерживать пиковые нагрузки, когда в дни акций и сезонных распродаж на сайт приходит на 200-500% больше покупателей, чем обычно. Архитектуру решения для такой ситуации трудно протестировать при ежедневной нагрузке.

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

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

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

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

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

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

Куда же без них? Например, в этом проекте мы сразу не подумали, каким образом лучше реализовать версию сайта для мобильных устройств: делать адаптивную верстку, мобильную версию сайта или разрабатывать приложение.

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

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

Это более дорогой вариант в разработке, но это разовое вложение средств в отличие от мобильной версии. Безусловно, мы должны были сделать это сразу, настояв на правильном решении.

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

Изначально все бизнес-процессы по разработке заводятся в систему управления проектом.

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

В системе управления проектами есть задачи четырёх видов:

График ниже наглядно демонстрирует, как после запуска лавинообразно возросло количество запросов на изменения и доработку (красная линия). Мы не успевали их выполнять. И зеленая линия показывает, каким было отставание по времени реализации запроса. Однако постепенно работа выстраивается, и примерно через 160 дней мы начали закрывать задачи с такой же скоростью, с которой они возникали.

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

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

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

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

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

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

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

Как в любом деле: хотите качественного результата — погружайтесь в работу вместе с подрядчиком.

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

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

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

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

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

В онлайне он может «отвалиться» в любой момент, особенно если заказ, оплата и доставка разнесены во времени. Чтобы не потерять клиента, это время нужно максимально сократить или чем-то занять. Здесь другие форматы работы с клиентами, и этому обязательно нужно учиться.

Через год после перезапуска сайта и старта мультиканальных продаж:

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

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

#Кейсы