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

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

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

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

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

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

Определяемся с задачами на разработку

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

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

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

Задача

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

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

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

Старт проекта

Расставляем приоритеты

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

Задача №1. Полная интеграция ERP- и CRM-систем с интернет-магазином: синхронизация остатков, заказов, данных пользователей, начисленных и потраченных бонусов

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

  • Полная интеграция с внутренней системой (в онлайн перенесли весь 20-тысячный ассортимент).
  • Наполнение контентом. Здесь мы работали совместно с заказчиком, поскольку в фэшн-индустрии максимально качественный контент — это главный фактор, влияющий на принятие решения о покупке. Было важно выложить описания и качественные фотографии для всего ассортимента. Начинали с трех фотографий на товар, сейчас их может быть до десяти.
  • Возможность найти и выбрать товар по бренду, цвету, размеру (пока без сравнения с другими и проверки наличия).
  • Отладка и упрощение процедуры заказа.
  • Запуск сразу на двух языках: украинском и русском.
  • Возможность в онлайне пользоваться привычными бонусными программами (в онлайн перенесли все данные пользователей).
  • Устранение дублей пользовательских данных и привязка бонусных карт​.

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

  • Со стороны заказчика​. Понимание, что волшебных платформ не бывает, какую бы ни взяли, она будет требовать доработки, а потом — поддержки. Быстрая обратная связь. Сотрудники начинают работать с системой и тут же могут сказать, что реализовано удобно, что — нет и что нужно исправить. Важно не замалчивать и не откладывать проблемы на потом.
  • Со стороны разработчика. Не делать сразу всю необходимую функциональность и на полгода погрузиться в проект, чтобы выдать какой-то результат. Определить совместно с клиентом минимально возможную функциональность, запустить как можно быстрее первый рабочий релиз и потом его доделывать, отлаживая бизнес-процессы на реальных рабочих ситуациях.

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

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

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

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

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

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

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

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

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

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

Данные пользователя в админ-панели менеджера
Данные пользователя в админ-панели менеджера

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

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

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

Задача №3. Частичное внедрение маркетинговых инструментов, не предусмотренных «Битрикс»

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

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

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

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

Управление показом ассортимента
Управление показом ассортимента

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

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

Маркетинг — рулевой продаж

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

Скидки и акции

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

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

  • Бонусные баллы.
  • Подарочные купоны.
  • Скидка 5% за эквайринг.​
  • Индивидуальная скидка на товар.

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

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

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

Накрутка бонусов

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

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

Функция «Проверить наличие в офлайновых магазинах»

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

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

Омниканальность

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

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

Омниканальность — это абсолютная свобода и удобство для пользователя: через какой канал взаимодействовать с продавцом, где купить и где получить товар и как воспользоваться своими скидками и бонусами.​

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

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

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

  • На 80% вырос трафик сайта.
  • На 55% вырос коэффициент транзакций.
  • В два раза выросло количество заказов с сайта.​

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

Алексей Сапунков, руководитель проекта со стороны Intertop

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

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

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

Момент перехода

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

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

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

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

Активная стадия проекта

Тонкости и нюансы

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

Спорная функциональность

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

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

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

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

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

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

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

Незадействованная функциональность

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

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

Пиковые нагрузки

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

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

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

График пользовательской активности
График пользовательской активности

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

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

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

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

Промахи

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

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

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

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

Коммуникации с заказчиком

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

Система управления проектом

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

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

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

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

  • Зеленые. Когда все согласовано, технические требования утверждены, и задачу можно брать в работу.
  • Жёлтые. Когда мы рекомендуем заказчику какую-то доработку (нам понятно, зачем она нужна, мы пишем обоснование и ждем, когда заказчик посмотрит наше предложение и примет решение).
  • Оранжевые. Это обнаруженные баги, требующие исправления, или мелкие технические доделки к уже выполненным глобальным задачам.
  • Красные. Это новые, пока неформализованные запросы со стороны заказчика (например, новый маркетинговый признак), по которым ещё нет никаких деталей​.

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

Динамика генерации инцидентов и их решения
Динамика генерации инцидентов и их решения

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

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

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

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

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

Константин Перепечаенко, руководитель проекта со стороны AniArt

Пользовательская документация

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

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

Пользовательская документация
Пользовательская документация

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

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

Заказчик против разработчика: степень вовлеченности

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

Участие в разработке с нулевого этапа

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

Перестройка процессов внутри

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

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

Перестройка процесса общения с клиентами

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

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

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

Кратко: как быстро и с наименьшими затратами для заказчика запустить ecommerce-платформу

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

Результаты заказчика

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

  • Рост заказов более чем в два раза.
  • Количество подписчиков сайта увеличилось в два с половиной раза.
  • Трафик сайта вырос на 80%.
  • Коэффициент транзакций увеличился на 55%.
  • Количество оплат заказов в онлайне банковской картой выросло на 40%.

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

Результаты разработчика

  • Три месяца от первой встречи до выхода первого релиза.
  • Интеграция ассортимента в 20 тысяч позиций.
  • Активная фаза разработки — семь человек, через год в разработке осталось два человека; в поддержке — три человека.
  • За 14 месяцев решено более 2400 задач.
  • Среднее время реализации задачи на разработку — 11,5 дней.
  • Среднее время устранения дефекта — 8,4 часа.

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

88
4 комментария

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

1
Ответить

Честно говоря я так и не понял, про перенос успешной офлайн практики в онлайн. То, что маркетинг из офлайна, наконец начал воспринимать онлайн не как "вещь в себе", а как часть огромного и живого организма, это хорошо. То, что все маркетинговые каналы интегрируются и агрегируют в одном месте данные это тоже очень хорошо, но кейс то в чем? В том, что все посыпалось в ERP систему?
И как всегда оторванные от жизни утверждения и цифры:

Рост заказов более чем в два раза. - По сравнению с чем/каким периодом? Среди новых/существующих клиентов? В штуках или деньгах (какие бумажки учитывали, или была произведена курсовая коррекция)? Произошла ли каннибализация офлайн продаж? За счет чего рост? Маркетинг денег подсыпал на рекламу? Или произвели оптимизацию по каналам привлечения? Или может скидок от души надавали, по факту выбрав инвестиционную модель продвижения? Кстати речь идет о подтвержденных или выкупленных заказах? Или разговор про "корзину"?

Количество подписчиков сайта увеличилось в два с половиной раза. - Как эти подписчики покупать стали? Вопрос про качество этих подписчиков.

Трафик сайта вырос на 80%. - Каналы трафика? % отказа? Это вернувшиеся или новые пользователи? Коэффициент целевых действий, в % соотношении с прошлыми периодами вырос или упал?

Коэффициент транзакций увеличился на 55%. - опять таки среди каких посетителей? Новых/вернувшихся? Может устройства лучше работать начали, например планшеты? Какое время покупки с момента первого привлечения? Может люди по 50 дней думают, прежде чем, что-то заказать. Или может было достаточно скорость загрузки сайта подтянуть и получить такие же цифры?

Количество оплат заказов в онлайне банковской картой выросло на 40% - Каннибализация какой формы оплаты произошла? В конечных деньгах, стало лучше/хуже?

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

Ответить

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

Ответить

Все верно, это кейс о проектном менеджменте со стороны девелоперов. описать как бывает на крупных проектах с высокой ценой ошибки. Кстати полную версию можно посмотреть здесь: https://www.aniart.com.ua/blog/detail/1068/
задаваемые вопросы об аналитике, но кейс не об этом )

Ответить