Почему Kanban для отдела продаж — это не просто описанная воронка в CRM
Я не планировал эту статью. Она родилась в ответ на несколько дискуссий, развернувшихся в профильных группах после моей первой публикации. В ней я слишком поверхностно описал применение Kanban в отделе продаж. Чем породил ряд недопониманий, которые и планирую устранить ниже.
Как следует из вышеуказанного определения, CRM — это программа. Т.е. продукт, созданный для автоматизации некоторых процессов. Но, как известно, если постараться автоматизировать беспорядок, то в результате получиться автоматизированный беспорядок.
А Kanban — это как раз метод для совершенствования процессов, которые по тем или иным причинам не удовлетворяют пользователей или заказчиков.
Kanban — это метод для определения, управления и совершенствования сервисов.
Действительно внедрение любой CRM системы начинается с описания пути взаимодействия с клиентом. Если мы строим его для отдела активных продаж (хантеров), то он будет представлять собой классическую воронку, которая начинается с попадания лида в систему, его первичную обработку, прояснения потребностей и т.д.
Kanban, по сути, на стартовом этапе предлагает сделать то же. А именно, визуализировать поток доставки ценности заказчику. Но дальше начинается работа над его усовершенствованием. Что, естественно, не предполагается в рамках программы, целью которой является автоматизация процесса.
После прояснения пути “доставки ценности” Kanban предлагает ограничить количество незавершенной работы в системе.
Т.е. установить лимиты на каждую из стадий прохождения лида по воронке. Как и зачем это делается, в подробностях опишу в следующих статьях, а сейчас лишь скажу, что таким образом мы начинаем управлять уровнем сфокусированности наших людей на необходимой нам работе и не даем заниматься более удобными для них задачами.
Также такой подход превращает нашу систему из проталкивающей во втягивающую. Мы не стараемся “напихать” как можно больше лидов в менеджера, а начинаем руководить его загрузкой, четче отслеживать блокеры по каждой из его задач, лучше понимать почему “срывается” тот или иной лид, да и, просто, яснее осознавать степень загруженности наших людей.
Далее Kanban предлагает определить точки принятия обязательств и “поставки” продукта.
Да, в хороших CRM также есть возможность отслеживать момент попадания лида в систему и момент его закрытия. Но есть несколько нюансов. Первый — сравнивают ли менеджеры системы скорость прохождения разных лидов от ее начала до конца? Если да, то какие делают из этого выводы? Kanban на основании этих данных предлагает выделить различные типы задач (в нашем случае лидов), выстроить по ним отдельную статистику, проводить регулярный анализ и совершенствовать систему в зависимости от его результатов (о нюансах также в следующих публикациях).
Второе — “точка принятия обязательств” носит такое название именно потому, что в данной точке команда, которая берет в работу некую задачу, берет на себя и обязательства выполнить ее в указанный срок с некой прогнозной вероятностью. Вы встречали хоть одну команду продаж, которая дает обязательства по закрытию лидов в момент взятия их в работу? Я — нет. Если знаете, поделитесь, пожалуйста!
Третье — хорошо, если все закрытые сделки априори прибыльны для компании. Но я встречал ряд организаций, в которых закрытая сделка еще не означала прибыльность клиента в долгосрочной перспективе. При этом, обычно, хантеры радостно “обмывают” подписанный контракт сразу после его закрытия и тут же бегут брать в работу следующий. А вот дальнейшее сопровождение клиента и его выгодность для компании — это уже “головная боль” фармеров (менеджеров по сопровождению действующей клиентской базы). Что естественным образом порождает конфликты между ними и не страхует компанию от возможных потерь.
Во избежание подобного Kanban предлагает в “точке поставки” проводить встречу с “заказчиком” и проверять все ли необходимые условия успешного закрытия задачи выполнены. Возможно, для кого-то это действие и избыточно, но для многих такая практика позволила бы сократить большое количество дальнейших ненужных затрат. Плюс на основании споров, которые при этом возникают, появляется понимание как улучшить проработку следующих лидов и систему в целом.
Ну и самое главное отличие Kanban-метода от простой аккумуляции данных в CRM.
Kanban предлагает в обязательном порядке создавать так называемые “петли обратной связи” или каденции — регулярные встречи по улучшению процесса. CRM, как программа, естественно, этого не требует. И в итоге у нас создается некая иллюзия контроля происходящего через монитор нашего компьютера. Где мы, конечно же, можем выявить какие-то проблемы и устранить их. Но эволюционно улучшать всю систему таким образом, на мой взгляд, у нас не получиться.
Для этого необходимо регулярное общение с людьми.
Kanban предлагает 7 видов каденций. О каждой из них, о рекомендуемом формате их проведения, тайминге и участниках также будет отдельная статья. Здесь же вкратце скажу, что обязательны нужны встречи по донесению до команд глобальной стратегии компании, а также ее корректировки на основании сведений, полученных с рынка (читай от людей).
Отдельные встречи для обсуждения сложностей во взаимодействии различных подразделений. Встречи для разбора основных блокеров в работе отдельных сервисов и формированию мер по дальнейшим улучшениям. А также регулярные встречи по планированию работ и оценке эффективности уже проделанных.
Без подобного общения может “умереть” любой, даже очень качественно автоматизированный, процесс.
В этот раз выводов делать не буду. Предлагаю их сделать самостоятельно.
Я как сотрудник компании, которая занимается разработкой и продажей CRM системы, уверен в том, что это очень полезная программа. Но факт ее наличия еще не определяет успешность методов управления ею.
Kanban — это метод для усовершенствования различного рода процессов. В том числе и автоматизированных с помощью CRM. Нужен он вам или нет — решать вам.
