Агропромышленный холдинг «Мираторг» – системообразующее российское агропромышленное предприятие, один из крупнейших поставщиков мяса на рынок РФ. Компания ведет полный цикл производства, самостоятельно изготавливает корма, выращивает животных, занимается мясопереработкой и реализацией готовой продукции через собственные магазины и торговые сети. Предпосылки к началу работы над проектом: – Менеджеры вручную, по телефону, принимали заявки на продукцию и оформляли заказ при выезде на торговую точку. Это неудобно для клиентов и составляет статью затрат для компании. – Нет каталога с продукцией. Его можно получить либо со сторонних источников информации, либо из разговора с менеджером. Сложный старт работы клиента с «Мираторгом», высокие операционные затраты. – Человеческий фактор при оформлении заказов неизбежно ведет к некоторому проценту ошибок. Их исправление влияет на лояльность клиентов и повышает затраты на их обслуживание. Задачи проекта Задача 1. Минимизировать человеческий фактор. Снизить, насколько это возможно, ручной контроль и возможность ошибки на протяжении всего жизненного цикла заказа. Задача 2. Упростить для клиентов процесс взаимодействия. Логика должна быть похожей на покупку в интернет-магазине: зашел, заказал, забрал. Задача 3. Создать прямой канал коммуникации с клиентом. Технологичный канал взаимодействия позволяет дать клиенту исчерпывающую информацию о продукции в удобном формате. Дополнительно – за счет push-уведомлений, баннеров и других способов управления вниманием – этот канал должен помочь в промоутировании новых линеек продукции. Задача 4. Сократить расходы. В первую очередь – затраты на менеджеров, составляющих заказ вручную посредством телефонного разговора и выезда на торговую точку. Задача 5. Наладить сбор обратной связи. Своевременно и централизованно получать информацию от клиентов, улучшать взаимодействие с нелояльными и поддерживать лояльных.
Бизнес-процесс и действующее backend-приложение были заточены под работу по старинке, через живого человека. Получается, что об особенностях и ограничениях каждого клиента и заказа мог знать только менеджер, составляющий заявку. Нигде, кроме как у него в голове, этой информации не было. Так что начать пришлось с того, что мы проанализировали действующей бизнес-процесс. Что предстояло сделать: 1. Вместе с бизнесом найти и формализовать ограничения – которые приложение должно было помочь обойти2. Разработать решения под каждое ограничение.3. Продумать эти решения – чтобы приложение оставалось гибким для доработок и отвечало best practice электронной коммерции. Как и в других подобных случаях – когда нужно решить реальную проблему бизнеса – мы использовали стандартный поэтапный подход:Бизнес говорит, какую проблему нужно решить. ↓Мы глубоко погружаемся в текущие процессы и показатели, чтобы исследовать проблему. Проводим аналитику, и готовим варианты решений. ↓Защищаем решения перед заказчиком. В процессе защиты обнаруживаются ограничения и рождаются идеи, как можно их обойти или решить, и выявляются дополнительные фичи, которые можно реализовать. ↓Вместе с заказчиком приходим к тому, как сделать лучше. Задача здесь – не только решить проблему. Важно, чтобы людям нравилось пользоваться мобильным приложением и возможностями, которое оно дает. Бывает, что интересы пользователя нужно защищать, доносить их ценность до бизнеса и аргументировать корректировки.↓ Делаем то, о чем договорились. Как раз в ходе обсуждений мы поняли, что приложение получается масштабным – как по функционалу, так и по закрываемым задачам бизнеса. Так что с ним точно еще потребуется работать дальше, после выпуска MVP в релиз.