формализация процесса доставки в Магнит Маркете

Я сейчас скажу не как «недовольный клиент», а как бизнес-аналитик.

Главная проблема всей этой истории с доставкой от Магнит Маркета — в том, что бизнес-процесс, судя по всему, вообще не формализован. Не «плохо реализован», не «сломался», а именно не описан и не собран как единое целое.

По ощущениям, было принято управленческое решение: сэкономить деньги и подключить партнёра — Яндекс — для доставки. Но при этом интеграция на уровне процессов не была продумана.

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

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

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

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

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

Ответа нет. По крайней мере, он не ясен ни магазину, ни курьеру, ни поддержке, ни клиенту.

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

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

Здесь этого нет. Мне никто не звонил. А если бы я уехал? Это базовый клиентский сценарий, даже без BPMN и UML — просто здравый смысл.

Поддержка в этой схеме — отдельный симптом. У поддержки нет единых инструкций. У магазинов нет единых инструкций. Версии происходящего противоречат друг другу. Это означает, что knowledge base либо отсутствует, либо не актуальна.

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

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

Вывод простой. Проблема не в курьере. Не в конкретном магазине. И даже не в поддержке.

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

А дальше можно сколько угодно вливать деньги в промо и бесплатную доставку — если процесс не собран, он будет разваливаться на каждом реальном клиенте.