CRM для дистрибуции
Я работаю в ИТ-дистрибуции больше 15 лет. За это время мне неоднократно попадались статьи и кейсы о внедрении CRM для ретейла, e-commerce, оптовых продаж, но информации о CRM для полноценной реализации двухуровневой схемы дистрибуции лично я не видел. И дело не только в том, чтобы в сделку добавить еще один уровень, всё гораздо сложнее: партнер и конечный заказчик – это два разных типа контрагента, к которым применяются разные бизнес-процессы как в маркетинге, так и в продажах. Не говоря уж о том, что у дистрибьюторов может быть разный подход к заказчикам: кто-то может и продавать напрямую, а кто-то, как в моем случае, использует информацию по заказчикам для развития рынка и аналитики.
Пример трехуровневой системы дистрибуции
О моем опыте
За последние пять лет я работал в дистрибьюторских компаниях разного масштаба: совсем небольших, средних, а также в одной из крупнейших. И если первая компания использовала типовую CRM чисто для учета контактов и взаимодействий, то во втором случае CRM пришлось создавать практически с нуля под бизнес-процессы компании. У дистрибьютора уровня Enterprise уже имелась CRM, самостоятельно написанная на готовой платформе. Но использовалась она кусочно, поэтому здесь приходится заниматься развитием системы в целом, а также объединением кусочков функционала в единую информационную картину.
Eсли говорить о главной цели CRM-системы в дистрибьюторской компании, то это, конечно же, повышение продаж. Оно происходит за счет построения аналитики, выявления и проработки узких мест. Также CRM позволяет увеличить конверсию по сквозным процессам – от стадии появления заказчика на радарах компании и выражения им интереса к продукции до конечной продажи через партнеров, а то и до послепродажных сервисов и дополнительных продаж. Причем бизнес-процессы могут быть самые разные. Для направлений массового спроса, например, полный процесс неактуален – никто не будет фиксировать заказчика для одного картриджа, покупаемого со склада. А для некоторых других направлений, возможно, наиболее актуальной задачей будет подбор аналогов.
И тут возникает вопрос – а откуда, собственно, берётся CRM?
Изначально для задач сбора и хранения данных о клиентах используются, как правило, прикладные инструменты вроде Excel или Outlook. Но при активном использовании (как по объему данных, так и по количеству одновременно работающих пользователей) они достаточно быстро перестают удовлетворять растущие потребности. Встает тема поиска специализированной системы и миграции (первой из ряда) накопленных данных. И поднимается вопрос: покупать что-то готовое или строить CRM самостоятельно?
Если брать типовую систему, даже большую и развитую, часто приходится подстраивать бизнес-процессы компании под нее. Для крупных компаний и/или имеющих сложившиеся специфические бизнес-процессы это крайне сложно. Что уж говорить о большом, широкопрофильном дистрибьюторе, у которого работы по разным направлениям могут кардинально отличаться в зависимости от специфики направления и опыта команды на нем. Не стоит забывать и о динамике в процессах, ибо и аппетит приходит во время еды, и мы живем в очень динамичном мире с меняющейся обстановкой, требующей изменения подходов. Да, разработчики типовых систем, как правило, постоянно развивают систему и добавляют новый функционал, но постоянно работать на одного клиента они не будут.
Самостоятельно писать систему – долго, сложно и дорого. Да и с разработчиками нынче дефицит. Промежуточный вариант, если нет собственных разработчиков, – аутсорс.
Плюсы и минусы системы, созданной на аутсорсе, находятся где-то посредине между этими двумя вариантами. С моей точки зрения, этот формат подходит для решения фокусных задач, но в глобальном масштабе слабо оправдан с точки зрения материальных затрат, оперативности и временных затрат на коммуникации.
По совокупности факторов, на мой взгляд, на текущий момент для средних и больших дистрибьюторов больше подходит вариант самостоятельной разработки. Отчасти это вызвано еще тем, что этот рынок слишком сложен и мал для готовых систем. Поэтому поговорим подробнее именно про разработку.
В чем сложность?
Один из первых вопросов, возникающих при собственной разработке: где должен находиться новый, «пограничный» функционал? В наиболее простом случае выбор предстоит сделать между ERP или CRM. Ответ на этот вопрос зависит от многих факторов, в частности от того, где гибче и быстрее разработка, где уже существуют структуры данных для работы этого функционала. Для себя я стараюсь придерживаться следующего правила: если бизнес-процесс происходит до продажи, то это развитие бизнеса и приоритетная система – CRM, если же после – то это учет и, соответственно, ERP.
Другой очень важный вопрос: как сделать так, чтобы сотрудники работали в системе? Поскольку у руководства компании могут быть свои цели, а у сотрудников – свои, недостаточно просто добровольно-принудительно заставить сотрудников работать в ИС. Конечно, можно попробовать, но в этом случае вероятность того, что процесс с течением времени будет подвергаться всё бòльшему саботажу, очень велика.
Чтобы сотрудники успешно начали работать в системе, необходимо соблюдать несколько основных условий:
- Должна быть видна ценность для сотрудника и для компании. И речь идет не только о прямой материальной стимуляции.- Система должна помогать сотруднику выполнять свою работу, а не добавлять ее. Требуется масса автоматизации для исключения рутины.
- Система просто должна быть удобной.
И выполнение этих пунктов надо постоянно проверять. Но чем больше компания, тем больше внутри нее требований, запросов, разных процессов, зачастую очень непохожих друг на друга. Функционал, требуемый от системы, разнится, разные подразделения компании работают по разным бизнес-процессам, видение путей развития системы у всех разное, если вообще есть.
Владелец продукта для CRM в дистрибуции: почему он необходим?
Нюансы, о которых я говорил выше, ведут к необходимости наличия сотрудника, ответственного за то, чтобы система приносила пользу компании – владельцу продукта. Это необязательно должен быть выделенный сотрудник: в зависимости от масштабов задачи этот человек может совмещать роль владельца продукта с выполнением других функций. Но если система реально важна для компании, то CRM должно уделяться не менее 50% усилий и времени.
Роль владельца продукта предполагает наличие разных компетенций: в частности, это аналитик, менеджер проектов, даже тестировщик. Очень желательны как технические, так и коммуникативные навыки. Последние – вплоть до умения «продавать» использование системы сотрудникам компании. То есть это вовлеченность, готовность с эмпатией вникать в проблемы пользователей и предлагать им решения проблем с помощью системы.
Необходимо понимание целей и нужд компании, а также того, как отдельный функционал поможет в их достижении. Очень кстати придутся практические навыки работы в качестве специалиста по конкретным направлениям. Иначе часто бывает непонятно, куда копать и какие потенциальные сложности, очевидные для пользователей, но совсем не очевидные для команды разработки, могут возникать.
Необходим взвешенный подход, чтобы найти баланс между реализацией всех хотелок и здоровым консерватизмом. Достаточное понимание последствий изменений в системе необходимо для того, чтобы не создавать функционал, который окажется лишним, дублирующим или противоречащим общей идее CRM.
Очень важны гибкость и способность адаптироваться к ситуации в моменте. Нужна готовность разобраться и сделать выводы из совершаемых ошибок (от них в ИТ никуда не деться) на будущее, и либо переделывать функционал для того, чтобы он имел практическую ценность, либо отказываться от его текущей реализации и решать задачу другими способами.
Основная цель, стоящая перед владельцем продукта, – добиться, чтобы CRM приносила пользу компании. А это включает в себя следующие задачи:
- Сбор требований к системе от разных групп пользователей, определение возможности включения затребованного функционала в реальную систему (иногда случаются ситуации, когда адаптировать систему невозможно, приходится делать полный рефакторинг отдельных разделов), наложение задумок на отраслевые практики, а также формирование понимания влияния этих задумок на продажи компании в целом.
- Визуализация идеального образа продукта, создание на его основе стратегии развития CRM.
- Понимание имеющихся данных, путей их очистки, логики взаимосвязей. Последнее очень важно! Это значит создание оправданных зависимостей где только можно. Двойная бухгалтерия просто отдыхает. Ибо данные, которые не вплетены в живое взаимодействие, обречены на отмирание.
- Объективное понимание текущего состояния системы и выработка тактики развития.
- Плотная работа с программистами и консультантами по реализации этих стратегии и тактики.
- Постоянная приоритизация и переприоритизация задач для оптимального использования ограниченных ресурсов.
- Обучение и вовлечение в работу пользователей системы, получение обратной связи и при необходимости корректировка стратегии и тактики.
И это постоянный процесс. В окружающем мире нет ничего неизменного – меняется как внешняя ситуация, так и внутренние ресурсы и процессы. Чем больше сотрудников вовлечено в работу в системе, тем больше возникает разнообразных хотелок. Часть из них являются сиюминутными или неприоритетными и их необходимо фильтровать и решать отдельно, например не через создание нового функционала, а через создание разовых отчетов или через привлечение аутсорсеров. А часть просто приходится откладывать на неопределенное время, так как их реализация слишком затратна и/или есть более приоритетные задачи с точки зрения компании в целом.
* * *
Итак, подытожим. Для дистрибьютора уровня Enterprise наилучшим вариантом является разработка собственной CRM-системы под бизнес-процессы. При этом развитие CRM – это творческий процесс, приносящий как большую пользу компании, так и глубокое собственное удовлетворение тем, у кого в крови стремление к упорядочиванию окружающего мира и к максимизации пользы для окружающих.
(Окончание следует)
Опубликовано 02.03.2023
