К нам часто попадают нестандартные проекты, и пожалуй это был самый нестандартный.
Вводные данные:
Крупный магазин бескаркасной мебели, со своим производством и множеством особенностей:
-
Работа разных отделов — розницы, партнеров (агенты), интернет-магазины, маркетплейсы, оптовики, корпоративные. Процессы разных направлений существенно отличаются.
-
Товары негабаритный, и стандартные модули считали неверно, а также сложно считать габариты когда товаров в заказе несколько.
-
CRM должна быть тесно связана со складом, производством и поставщиками.
-
Большинство товаров — комплекты, с разным сроком производства, также разные виды номенклатур.
-
Сложная система резервирования, товары должны резервироваться по разному, в зависимости от вида номенклатуры.
-
В разных каналах разные товары с разными типами цен. Причем любой товар мог быть услугой — например аренда товара на разный срок.
-
Бесплатные товары, а также сразу несколько видов услуг в одном заказе.
-
Сложная система оплат, с разными договорами поставки, в т.ч. с отсрочкой платежей.
-
Большие затраты на рекламу, необходимо связать затраты на рекламу и продажи, рассчитать ROI
-
Синхронизация существующих клиентов и контактных лиц в 1с, сайтах, RetailCRM
Все это еще и осложнялось что клиент полгода поработал с другим интегратором, и за это время интегратор сделал интеграцию только с одним сайтом, а самое главное — бизнес-процессы даже не обсуждались, поэтому сотрудники и руководство уже теряли мотивацию и нужны были быстрые результаты. Итого проект состоял из 116 различных задач, 30 из них — доработки логики 1с.
Результатом должно было быть — что все менеджеры работают в RetailCRM, в 1с- УПП работает производство, закупка, доставка и бухгалтерия. В CRM нужно было полная работа менеджеров и их коммуникации, а также аналитика.
Бизнес-процессы и взаимодействие с производством в 1С
Бизнес-процессы в зависимости от бизнес-направления (подразделения) существенно отличались, перечислю основные моменты.
Разные типы заказов обрабатывали разные подразделения, поэтому при поступлении заказа — он сразу распределялся на нужных менеджеров и проходил через разные статусы и разные механизмы контроля. Менеджеры интернет-магазина фокусировались только на приеме обращений и контроле получения оплат.
Статусы делились на 10 групп, но такое количество в основном из-за того что разные направления работали по разным схемам оплаты-отгрузки. Но все процессы связанные с оплатами, отгрузкой были автоматически. Т.е. менеджеры должны были только принять заказ, согласовать дату поставки, формат оплаты, дальше все контролирует CRM. Если оплата, производство, или доставка выходила за контрольные показатели — заказ автоматически переходил в специальные статусы «тайм-аут» который сигнализировал о проблеме.
Т.к. все производство, запасы, поставщики работало в 1с — требовалась глубокая интеграция многих процессов.
Товары не производились под конкретного клиента. Производство планировалась спринтами на 2 недели, и одинаковых позиций вышивали сразу в больших количестве. Т.е. могли быть следующие состояния товаров:
-Товар в наличии на складе
-Товара нет и не планируется.
Мы организовали все через статусы товаров по такой схеме. Важно именно по товарам, т.к. в одном заказе могло быть множество товаров на разных стадиях производства.
|
Статус товара в CRM
|
Значение
|
Статус товара в 1С
|
|
Добавлен
|
Изначальный статус по умолчанию
|
—
|
|
Запрос наличия
|
Менеджер видит возможность зарезервировать и дает сигнал в 1С для подтверждения
|
— |
|
Резерв на склад
|
1С подтвердило наличие товара на складе, и товар готов к отгрузке
|
Документ «Резервирование товаров» — основной склад
|
|
Резерв в Заказ поставщику
|
1С видит, что товара нет, но есть Заказ поставщику, и резерв пошел в Заказ поставщику
|
Документ «Резервирование товаров» — в «Заказ поставщику»
|
|
К обеспечению
|
Товара нет ни в наличии, ни в Заказе поставщику. Переход К обеспечению
|
—
|
|
Не обеспечивать
|
Товар не надо обеспечивать, идет согласование с клиентом
|
—
|
|
Возврат
|
Возвращен клиентом, в 1С сделан Возврат на этот заказ и товар
|
Документ Возврат товара и услуг
|
Для облегчения — менеджер сразу получал в заказ ближайшую возможную дату отгрузки товара, с учетом всего производства
Интересный момент резервирования. Т.к. все товары это комплекты — состоят из 3-7 разных компонентов, часть товаров были уникальные и изготовлялись на производстве (например чехлы), а часть были универсальны и всегда были в наличии (наполнитель). Поэтому в 1с товар попадал товар как комплект, а при резервирование уже раскладывался на составляющие, и резервировался на отдельных складах или заказывался у поставщика
Сроки поставки всего товара были ограничены поставкой или производством самого «последнего» товара. И такая группировка по разным складам и поставщикам — позволяла определить дату доступности товара.
Для упрощения мы условились что производство — это тоже поставщик (внутренний), что существенно упрощало процессы. А по заказам на внутреннего поставщика строился как раз производственный календарь.
т.к. могли происходить корректировки заказов — отмены, возвраты или брак, и просто корректировка производства — регламентные задания проверяли изменения и корректировали остатки и документы.
Договора.
Договора должны были выбираться по сложным условиям — в зависимости от канала продаж, типа оплат и величине предоплаты. Фактически везде где была частичная оплата, генерировался новый договор, и подставлялся. Этот ужасный костыль использовался уже много лет, и пришлось очень сильно настоять, чтобы сделать правильную систему договоров.
Чтобы не делать сложные механизмы в самом коде обмена и можно было гибко менять — выбор юр. лица, вид договора, касса выбирался как справочник в RetailCRM, и подставлялся автоматически триггерами. Это позволило быстро вносить изменения без правок в обмене retailCRM-1c или менять принудительно в заказе, без перехода в 1с.
Оплаты.
Часть оплат создавались из 1с в RetailCRM, например — все платежи по банку, терминалы, оплаты на счет от ТК, получение денег курьером. Т.е. в зависимости от выбранного типа оплаты и доставки — создавался нужный счет в 1с и ожидал оплаты, после оплаты он становился оплаченный и в RetaIlCRM.
Оплаты же которые принимали менеджеры — предоплата наличными в магазине, через терминал постоплата, эквайринг, подарочные карты — создавались менеджерами в CRM и создавались автоматически нужные документы в 1с. Итого 10 разных типов оплат.
Кроме этого в зависимости от канала-продаж, были разные ценовые колонки. Товары тоже могли быть переданы в аренду, на разный срок — т.е. эти же товары могли стать услугой. Мы решили эту задачу через ценовые колонки в RetailCRM. Получилось 16 типов цен, но они выбирались автоматически в зависимости от разных условий заказа, и менеджер не думал об этом.
Номенклатура.
Продажи осуществляются с разных сайтов и на площадках. На каждом сайте своя иерархия и некоторые отличия в номенклатуре. Т.к. важно было понимать просмотренные товары клиентом, было решено использовался с каждого сайта свой каталог и один каталог дополнительный — каталог комплектующих и доп. услуг. При передаче в 1с одинаковые товары с разных каталогов объединялись, и в 1с никаких дублей не было.
Модуль доставки.
Т.к. товар сильно габаритный — и некоторые службы просто могли не взять такой заказ или стоимость сильно отличалась, был создан специальный внутренний модуль расчета доставки, который учитывал данные доставки, и рассчитывал доставки сразу по нескольким службам доставки, и предлагал лучшее. После этого уже оформлялся через выбранный тип доставки или передавался на собственную логистику.
Прочие Интеграции в RetailCRM
Т.к. основная цель была все сделать в одном приложении, также в RetailCRM были интегрированы все используемые сервисы: instagram, whatsapp, Jivasite, телефония Uis, Sendpuls, google analytics, эквайринг, несколько аккаунтов Ozon. Также были сделаны различные печатные формы, письма, опросники для клиентов после заказа, десятки триггеров и валидаций для тонких прав разных групп менеджеров и руководителей.
Итоги
В начале проект казался очень сложный и сумбурный, и во многом приходилось разрабатывать логику и реализовывать в сжатые сроки. RetailCRM удобный инструмент для продаж, и при грамотном подходе можно приспособить под очень разные направления бизнеса — ecom, розница, партнеры, дилеры, маркетплейсы. Фактически в одном окне получили управление продажами, заказы на производство, прием платежей, расчет негабаритной доставки, аналитику, чаты, рассылку, телефонию и соц. сети.
Лично от себя (Сергея Ткаченко), мы получили большой опыт не только технический, но в собственном развитии. Когда мы уже заканчивал проект, я спросил заказчика — почему сразу нас не выбрали, вы же обращались? Ответ сильно удивил: — «Когда мы обзванивали партнеров, вы единственные сразу отвечали: да это можно, это можно, это легко. Тогда нас это сильно оттолкнуло, т.к. другие интеграторы сомневались вообще в реализации проекта. Сейчас конечно мы не сомневаетесь в вашем опыте». Большое спасибо клиенту, за такую обратную связь, с тех пор перевел обработку входящих звонков на отдельного менеджера, и конверсия существенно выросла
