“Х’юстон, у нас проблеми”. Як в Kasta, Multiplex, Zakaz.ua і Comfy виходять з проблемних ситуацій

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

Цей текст доступний також російською мовою

Портал MC Today напередодні Третьої виставки індустрії рітейлу та девелопменту Retail & Development Business Expo-2019 розпитав спікерів заходу про їх провали в бізнесі і рішеннях, з якими їм довелося змиритися. Захід, який відбудеться 28-29 березня 2019 року в Києві в НСК “Олімпійський”, збере представників компаній сфер роздрібної торгівлі, девелопменту, інвесторів, брокерів і консультантів, компаній сегменту B2B.

Чому закрили сервіс GlobalKasta. Розповідає Наталія Логвин, PR-директор Kasta

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

У травні того ж року ми запустили форвардинговий сервіс GlobalKasta – доставка посилок з США. Метою проекту було дати українцям свободу вибору і легкий доступ до асортименту більшості американських онлайн-магазинів. Ключовими конкурентними перевагами ми заявили вартість послуги, швидкість і безпеку доставки. Незважаючи на якусь турбулентність при запуску, через три місяці ми змогли вийти в лідери ринку “форвардерів” України за кількістю доставлених посилок з США.

Труднощі почалися в кінці року, в розпал сезону свят. Почастішали затримки з доставкою, що сильно відбилося на планах і очікуваннях клієнтів, які активно купували подарунки і користувалися початком сезону розпродажів в Америці.

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

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

До слова, тепер у Kasta.ua всі ключові процеси компанії – інхауз. Це команда розробників платформи, онлайн-маркетинг повного циклу, власний сервіс доставки, мережа відділень, складська логістика, фото і відеопродакшн, фінансова система, контакт-центр та інше.

Як у нас не “зайшла” доставка продуктів з ринку “Столичний”. Розповідає Андрій Курський, гендиректор Zakaz.ua

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

Однак після запуску ми зіткнулися з серйозними труднощами:

• На ринку не було фіксованого асортименту, тому ми не могли гарантувати покупцеві наявність товарів.
• Зафіксувати ціни було неможливо, через що збирачу доводилося розмовляти з клієнтом майже по кожній позиції і доповідати про ситуацію з асортиментом і ціною.
• В момент доставки ми не могли надати касовий чек, клієнтам доводилося вірити нам на слово.
• Збирачі витрачали багато часу на переміщення по павільйонах, на вибір продуктів і торги з продавцями.

Через деякий час нам довелося призупинити послугу доставки зі «Столичного», щоб не нести фінансових втрат. Але завдяки цьому невдалому експерименту ми змогли вибудувати оптимальну модель роботи з вже організованими рітейл-мережами.

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

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

Три роки потому у нас в арсеналі з’явилися новий сайт, додаток, CRM, особистий кабінет і багато чого ще. Той співробітник став начальником цілого відділу. От тільки програму лояльності ми досі не запустили. Тому що в процесі виявилося, що для правильної її роботи потрібна сильна інфраструктура, якої просто не було.

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

Як один прорахунок в системі мало не поховав всі продажі в “чорну п’ятницю”. Розповідає Сергій Гаврилов, IT-директор Comfy

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

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

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

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

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

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

Відповідно, план «Б» потрібен завжди. По-друге, при проектуванні архітектури варто пам’ятати, що найкраще – ворог хорошого. У нашій ситуації, якби не було «занадто розумного» балансера, не було б ефекту сніжної грудки. По-третє, в ідеалі, різні функції в системі повинні бути реалізовані в максимально ізольованих один від одного модулях, щоб було максимально знижено їх взаємний вплив.

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

Читайте також –

Провал операції: найгучніші скандали в українському рітейлі в 2018 році