«Хьюстон, у нас проблемы». Как в Kasta, Multiplex, Zakaz.ua и Comfy выходят из провальных ситуаций

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

Хьюстон, у нас проблемы: сложные решения при факапах – опыт Kasta, Multiplex, Zakaz.ua и Comfy

Организаторы выставки индустрии ритейла и девелопмента Retail & Development Business Expo-2019 по просьбе MC Today расспросили спикеров мероприятия об их провалах в бизнесе и решениях, с которыми им пришлось смириться.

Почему мы закрыли GlobalKasta. Рассказывает Наталия Логвин, PR-директор Kasta

В начале 2016 года мы почувствовали, что после кризиса 2014-2015 года в Украине «вымылись» стоки (одежда и обувь), и все чаще стали слышать пожелания от клиентов добавить новые продукты на сайт. После долгих дебатов и мозговых штурмов, как дать возможность покупать клиентам любимые бренды, мы остановились на неожиданном решении.

В мае того же года мы запустили форвардинговый сервис GlobalKasta – доставка посылок из США. Целью проекта было дать украинцам свободу выбора и легкий доступ к ассортименту большинства американских онлайн-магазинов. Ключевыми конкурентными преимуществами мы заявили стоимость услуги, скорость и безопасность доставки. Несмотря на некую турбулентность при запуске, через три месяца мы смогли выйти в лидеры рынка «форвардеров» Украины по количеству доставленных посылок из США.

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

Мы проанализировали ситуацию и поняли, что в цепочке создания ценности продукта GlobalKasta кроме нас присутствовало еще 3 звена: склад в США, перевозчик, таможня. В результате с нашей стороны мы могли обеспечить контроль качества продукта лишь на ¼ часть, а шквал негатива в полном объеме был направлен исключительно в наш адрес. Решение о закрытии было тяжелым, но быстрым: 1 февраля 2017 года мы официально закрыли сервис.

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

К слову, на сегодня в Kasta.ua все ключевые процессы компании – инхауз. Это команда разработчиков платформы, онлайн-маркетинг полного цикла, собственный сервис доставки, сеть отделений, складская логистика, фото и видеопродакшн, финансовая система, контакт-центр и прочее.

Как у нас не «зашла» доставка продуктов с рынка «Столичный». Рассказывает Андрей Курский, гендиректор Zakaz.ua

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

Однако после запуска мы столкнулись с серьезными трудностями:

1) На рынке не было фиксированного ассортимента, поэтому мы не могли гарантировать покупателю наличие товаров.

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

3) В момент доставки мы не могли предоставить кассовый чек, клиентам приходилось верить нам на слово.

4) Сборщики тратили много времени на перемещение по павильонам, на выбор продуктов и торги с продавцами.

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

Как мы за три года так и не запустили программу лояльности. Рассказывает Виталий Писаренко, гендиректор Multiplex

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

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

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

Как один просчет в системе чуть не похоронил все продажи в «черную пятницу». Рассказывает Сергей Гаврилов, IT-директор Comfy

В канун «черной пятницы» 2018 было понимание того, что нас ожидает резкий всплеск нагрузки на все системы. Провели нагрузочные тесты, выявили и оптимизировали медленные блоки логики – показатели очень красивые, все готово к бою!

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

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

А поскольку каждый сервер приложений ERP был полнофункциональным, то есть реализовывал весь доступный функционал, то один проблемный вид запросов загрузил все сервера – и перестало работать все остальное.

Что характерно, интернет-магазин прошел этот период с меньшими потерями, поскольку там был заготовлен план «Б» на случай, если ERP таки начнет сбоить. А для POS-системы решили план «Б» не делать, так как его реализация выглядела слишком сложной, а результаты тестирования были более чем оптимистичными.

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

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

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