Внедрение RetailCRM с производством на базе УПП

Внедрение RetailCRM с производством на базе УПП

К нам часто попадают нестандартные проекты, и пожалуй это был самый нестандартный.

Вводные данные:

Крупный магазин бескаркасной мебели, со своим производством  и множеством особенностей:

  1. Работа разных отделов — розницы, партнеров (агенты), интернет-магазины, маркетплейсы, оптовики, корпоративные. Процессы разных направлений существенно отличаются.
  2. Товары негабаритный, и стандартные модули считали неверно, а также сложно считать габариты когда товаров в заказе несколько.
  3. CRM должна быть тесно связана со складом, производством и поставщиками.
  4. Большинство товаров — комплекты, с разным сроком производства,  также разные виды номенклатур.
  5. Сложная система резервирования, товары должны резервироваться по разному, в зависимости от вида номенклатуры.
  6. В разных каналах разные товары с разными типами цен. Причем любой товар мог быть услугой — например аренда товара на разный срок.
  7. Бесплатные товары, а также сразу несколько видов услуг в одном заказе.
  8. Сложная система оплат, с разными договорами поставки, в т.ч. с отсрочкой платежей.
  9. Большие затраты на рекламу, необходимо связать затраты на рекламу и продажи, рассчитать ROI
  10. Синхронизация существующих клиентов и контактных лиц в 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, розница, партнеры, дилеры, маркетплейсы. Фактически в одном окне получили управление продажами, заказы на производство, прием платежей, расчет негабаритной доставки, аналитику, чаты, рассылку, телефонию и соц. сети.

Лично от себя (Сергея Ткаченко), мы получили большой опыт не только технический, но в собственном развитии. Когда мы уже заканчивал проект, я спросил заказчика — почему сразу нас не выбрали, вы же обращались?  Ответ сильно удивил:  — «Когда мы обзванивали партнеров, вы единственные сразу отвечали: да это можно, это можно, это легко. Тогда нас это сильно оттолкнуло, т.к. другие интеграторы  сомневались вообще в реализации проекта. Сейчас конечно мы не сомневаетесь в вашем опыте».      Большое спасибо клиенту, за такую обратную связь, с тех пор перевел обработку входящих звонков на отдельного менеджера, и конверсия существенно выросла

Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии