Сложный путь пельменей. Или как мы автоматизировали обработку всех обращений в крупной продуктовой компании

Мы часто рассказываем о крутых проектах по автоматизации, которые запускаем в самых разных компаниях. На самом деле таких историй у нас намного больше, чем выходит в печать. Однако в большинстве случаев мы не можем называть заказчика, а поделиться хочется. Поэтому решили описывать кейсы анонимно. Все совпадения с реальными компаниями — совершенно (не)случайны

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

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

И с этим у заказчика были связаны 3 главные бизнес-боли.

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

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

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

3. Обращения по заявкам на отгрузку / заказы. С этой огромной болью сталкиваются все агропредприятия. Дело в том, что им приходится постоянно регулировать переизбыток продукции — например, много мяса образовалось или картошки выросло. И такие излишки они выставляют на аукцион. Но у компаний, которые выигрывают торги, нет обязательств выкупать товар. И они этого довольно часто не делают. Соответственно, производитель сталкивается с гигантской проблемой — есть излишки, они портятся, их нужно просто выбрасывать. Убытки.

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

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

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

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

Вроде бы ничего сложного — буквально за месяц должны были все сделать. Но…

В реальности проект растянулся на несколько месяцев. Почему так произошло?

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

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

То есть нам нужно было провести интеграцию не с одной ERP, как изначально планировалось, а с двумя. И это было бы не критично, если бы не отсутствие у них единой нормативно-справочной информации (НСИ). То есть в одной системе клиент записан как ООО “Ромашка”, в другой — группа компаний “Ромашковое поле”.

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

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

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

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

Третье — особые требования заказчика к системе. Они базировались на «трех китах»: интерфейс, мотивация и персонал.

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

Мотивация. Нужно отдать должное руководителю проекта со стороны заказчика, т.к. он параллельно проводил работу со своими сотрудниками и внедрил систему мотивации. Заключалась она в следующем: по умолчанию каждый сотрудник плюсом к зарплате получал 100% бонусов. Но эти 100% сотрудник получал, если вносил данные в CRM корректно, и в его показателях в этой системе было все ОК. Если данные вносились некорректно, то бонус уменьшался пропорционально количеству ошибок и неточностей.

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

Первую часть проекта мы успешно завершили. Была внедрена система контроля всех обращений. Теперь отдел качества использует данные клиентского сервиса для системных изменений в процессах.

Компания получила:

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

*Победный танец*

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

Как все устроено. Все обращения от всех типов заказчиков поступают в CRM. Она контролирует скорость их обработки, все действия, которые должны быть выполнены пользователями и т.д. Потом некоторые обращения становятся заявками на отгрузку. И здесь вступает в работу очень интересный бизнес-процесс, который на местном сленге называется “делилка”. Это звезда смерти в этом проекте :)

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

В итоге во втором проекте мы пришли к такому решению. Расчеты мы оставили в ERP, а процесс перенесли в CRM. Процесс управляет людьми, их действиями и действиями людей в других системах, не только в CRM, а «делилка» производит расчеты, которые приводят к правильному распределению продукции между покупателями и внутри производственной цепочки.

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

Хеппи енд!

#история_одного_проекта #omniline

Больше информации о технологиях, клиентском сервисе, автоматизации вы найдете на нашем сайте, в Telegram-канале и на нашей странице в Facebook