Как автоматизировать обработку заказов и не копаться в «эксельках»

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

Наш клиент — производитель крепежа и строительного оборудования. Более 20 тысяч контрагентов заказывают товары компании. Это оптовый бизнес с высоким средним чеком и большими партиями отгрузок.

Изначально у клиента была простая CRM-система, ничем не лучше «Экселя». В ней не было единой структуры продаж, а заказы обрабатывались по нескольку дней или вовсе терялись.

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

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

С инфраструктурой тоже были проблемы. Офисы не объединялись между собой: в каждом регионе была своя «1С», своя телефония и свой почтовый сервис. Все это сильно тормозило процессы, и компания стагнировала.

Проект масштабный и одной интеграцией CRM тут не обойтись, нужно было действовать глобально и выстраивать логику всех процессов.

Мы решали непростую задачу: перестроить структуру работы компании и автоматизировать сложные процессы. Основной KPI — выставлять КП за 2 часа с момента получения заказа.

Мы разложили процесс на несколько этапов:

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

Файлы контрагентов вручную собирались из разных источников и подготавливались. Операторы сами сопоставляли заказы с внутренней номенклатурой и заносили их в «1С».

Пример того, как клиенты, заказывая одну и ту же позицию, называют ее по-разному. И того, что происходит после сопоставления.

В дополнение ко всему была CRM-система. В нее менеджеры просто добавляли клиентов, но не проводили по ней продажи и сделки.

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

Мы проработали логику системы. Теперь заказ обрабатывается через специальный сервис сопоставления номенклатуры. Параллельно проверяется контрагент, заказ и остатки товара. Плюс «пробрасываются» данные в CRM для анализа сделки.

В жизни процесс стал выглядеть так:

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

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

Пример. Строим CRM для call-центра в 500 сотрудников. Менеджеру нужно сегментировать клиентов по 10 типам, у каждого типа свои сценарии и этапы воронки. В случае с амо менеджеры просто запутаются в какую воронку и по каким этапам нужно вести клиента. Это должен быть четкий алгоритм, в котором вероятность ошибки сводится к нулю. Но амо не поддерживает гибкие сценарии.

В Terrasoft можно строить гибкие сценарии и развилки процессов. Сделки автоматически переносятся по этапам в соответствии с процессами. Менеджер не должен переводить сделки по воронкам. Все происходит по сценарию при выполнении задач.

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

После сборки CRM увидели, что заказы обрабатываются очень долго. 23 оператора сопоставляли заказы по несколько дней — стали думать, как сопоставлять их автоматически.

Хотели сделать AI для сопоставления, но поняли, что объема данных не хватит.

Поэтому решили использовать Elasticsearch. Обычно его внедряют как поисковик на сайтах. Он основан на механизмах токенизации для сопоставления текстов. То есть «перегоняет» текст в токены, дальше токены сопоставляются с базой данных. На выходе — комбинация из сопоставленных позиций.

На основе этого метода мы сделали отдельную систему сопоставления заказов — Elastic. После сопоставления заказ выгружается в «1С».

В нашем случае мы сделали так, чтобы Elastic сопоставлял номенклатуру и остатки вместо операторов. Операторы в свою очередь обучают его: проверяют корректность сопоставления и отправляют связки в черные и белые списки. Чем больше сопоставлений сделает система, тем точнее она будет работать.

Существуют связки данных: «Клиент» → «Номенклатура из документа» → «Номенклатура из 1С».

Если связка попала в белый список, значит она была ранее успешно сопоставлена. В дальнейшем такая связка будет использоваться повторно, уже без elasticsearch.

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

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

После сопоставления списка товаров c загруженного файла система отобразит данные в таблице:

Оператору необходимо только проверить корректность сопоставления всех записей — обучить систему.

Когда мы собрали Elastic и начали тесты — поняли, что не весь каталог актуален. В товарном каталоге 20 тысяч позиций, но в наличии только 5000. Значит и сопоставляться нужно только с 5000 — в этом был небольшой косяк. Изначально мы не учли обновления каталога, пришлось доработать эту возможность.

Пересчет фасовок и объемов планировали сделать во второй итерации. Но на тестах поняли, что без него никуда. Теперь все заказы приводятся к единой системе измерения. Прямо как данные задач из учебников физики приводятся к СИ.

Клиенты и менеджеры присылали файлы в совершенно разных форматах. Фасовку и вес могли присылать в названии файла. Пришлось сделать распознавание и вычленение параметров заказа из всего присланного документа/файла.

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

На полное проектирование, внедрение CRM, разработку системы и интеграций ушло ровно 3 месяца.

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

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

Аналитика. Показатели менеджеров теперь собираются внутри CRM. Руководители видят время обработки заказов, срезы по работе менеджеров и операторов.

Также мы собираем данные по обучению Elastic, чтобы понимать его эффективность.

Цели. Выполнить KPI — это хорошо. Но задача клиента — оптимизировать процессы и расходы.

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

Задайте себе вопрос: «Чего я хочу на выходе?»

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

Интегратор — LAND PRO. Редактор статьи — Фёдор Анисимов.