А проблема в слабой предсказуемости такого процесса.
Начнем с моего любимого вопроса: зачем. Зачем нужно описание процесса продаж (В2В, т.е. когда продает бизнес бизнесу)?
Основная цель — получить некие вехи, промежуточные этапы, по которым можно судить об успешности работы продавцов и тем самым контролировать процесс. Могут быть еще дополнительные цели, например, чтобы поставить работу продавцов в соответствие с процессами других подразделений или чтобы было проще унифицировать работу разных сотрудников, особенно, если они работают недавно (и тут будет законным вопрос — зачем ее унифицировать — но не будем отвлекаться пока что).
Но основная цель, обычно, — контроль.
Естественно, достаточно часто, когда речь идет о продаже серьезных решений, есть соблазн не вмешиваться в работу специалистов по продажам и предоставить их самим себе. Особенно, если они показывают результат.
Однако, в какой-то момент случается так, что результата нет, и тогда хочется разобраться, а что же вообще делалось, раз ничего так и не сделано, — по крайней мере не сделано так, чтобы получить тот самый результат.
И тогда может оказаться, что специалисту по продажам (продавцу, менеджеру по продажам, вице-президенту по продажам и т.п.) очень сложно отчитаться о том, что конкретно вообще было сделано. И у руководства естественным образом может возникнуть желание все-таки контролировать и процесс тоже, а не только результат. Чтобы отрицательный результат не стал сюрпризом к концу отчетного периода.
О разных подходах к описанию процессов напишу отдельно, сейчас рассмотрим процессы с точки зрения начальных событий и развивающихся после этого различных действий.
Предположим, что лиды — это забота маркетинга (вообще-то так и должно быть, в большинстве случаев, за исключением реферальных рекомендаций и личных связей продавцов), тогда начальным событием может быть получение такого лида продавцом от маркетинга.
Что делает продавец в таком случае? Ну, наверное, неплохо бы изучить лид немного подробнее, затем попытаться выйти на контакт — или сразу выйти на контакт, если маркетинг любезно об этом уже договорился (да, так делают, это нормальная практика).
Далее начинаются слабо предсказуемые движения от звонков к встречам, от имейлов к звонкам, от встреч до звонков и имейлов, когда совершенно не факт, что процесс уложится в какой-то понятный алгоритм.
Поэтому обычно в таких случаях говорят о т.н. happy way, т.е. процессе, который идет по "счастливому пути", идеально.
Опять же, зачем, если в реальности он может пойти очень витиевато? А чтобы обозначить те самые вехи. Никто не собирается укладывать В2В-продавца в прокрустово ложе жесткого алгоритма, это вряд ли получится, но хотя бы обозначить вехи — уже можно попробовать.
Получаем, что в реальности продавец делает непонятное количество разной успешности звонков, имейлов, встреч, презентаций и т.п., но мы это отражаем не столько действием, сколько предполагаемым действием и статусом клиента на разных этапах.
Следующая проблема: продавцы склонны завышать ожидания. Чтобы избежать выгорания и упорно делать сложную работу, продавцы вынуждены быть супер-оптимистами, хотя бы формально (неформально они потом могут бухать по вечерам в глубокой депрессии), иначе будет сложно оставаться достаточно настойчивым и продолжать делать свою работу.
Но для трезвого анализа такой настрой не годится, нам нужно четко понимать вероятность заключения сделки.
Стандартный прием, который часто предлагают даже очень (очень, реально) уважаемые агентства, — присваивать некую вероятность на каждом этапе. На глазок.
Понимаю это, когда не выходит сложить статистику. Но сейчас-то со статистикой проблем быть не должно. Можно же посчитать, сколько лидов из состояния А перешло в состояние Б (т.е. т.н. конверсию), отсюда посчитать более-менее реальный прогноз, а не от потолка ставить 50% вероятности всем на этапе коммерческого предложения, к примеру. А может там реально всего 5%, что ж себя обманывать так жестоко.
Т.е. решение понятно — настраиваем отчет и учитываем статистику, а уже отсюда, а не от эмоциональных ожиданий продавцов, делаем прогноз.
Так что с процессом? Получается, что можно сделать что-то вроде образцового алгоритма, который вряд ли повторится в жизни, но который позволит обозначить определенные действия и получать показатели по этим действиям.
Сразу скажу, это не золотой ключик и проблему не решит. Проблему решает качественная продажа, а это — всего лишь один из разновидностей контроля работы, не более того. Но это важно, если руководитель хочет руководить, а не просто слушать отчеты о результатах и в зависимости от успешности ругать или хвалить подчиненных.
Приведу пару примеров. Один случай описан Нилом Рэкхэмом: в компании решили улучшить показатели путем увеличения количества встреч продавцов с потенциальными клиентами. Но результат оказался противоположным: продавцы, вынужденные проводить больше встреч, стали хуже к ним готовиться, им не хватало времени, поэтому встреч стало больше, но сделок, вопреки ожиданиям, — меньше. Не всё решают цифры, цифры могут помочь понять суть, но саму суть при этом игнорировать не следует.
Еще пример: некая компания обнаружила, что наибольшее количество отказов клиентов приходится на конец месяца. Исследование этого феномена вскрыло следующую вещь: продавцы к концу месяца пытались нагнать план, поэтому действовали излишне агрессивно, что давало обратный результат и наоборот, понижало количество сделок. Вот тут как раз цифры дали повод посмотреть, а реальное вникание в проблему натолкнуло на решение: уменьшить отчетный и плановый период для продавцов с месяца до недели, чтобы у них не было соблазна оставлять на конец месяца всю работу.
Вернемся к описанию процесса, к чему мы пришли?
Получается, что описать процесс точно — не вариант. Слишком много непредсказуемых моментов. Можно в "большом" процессе эти моменты запихнуть в т.н. ad hoc подпроцесс (когда просто перечислены действия, но их порядок не регламентирован), можно описать "счастливый" вариант, без требования жестко ему следовать.
Второе в последнее время достаточно популярно. И применяется вместе с управлением кейсами (грубо говоря, кейс — когда мы не знаем точный алгоритм последующих действий, при этом их выбор — на совести исполнителя). Например, предлагается идти "по процессу", но исполнитель может отклониться в любой момент и система автоматизации ему это позволит.
Показатели при этом все равно считываются по действиям, так что можно выбрать ключевые и по ним попытаться увидеть общую картину.
Автоматизация при этом заключается, обычно, в следующем:
- фиксация действий исполнителей;
- выполнение различного рода автоматических скриптов (информирование, формирование документов, составление отчетов и т.п.), сюда же формирование отчетности для аналитики;
- "подсказка" исполнителю следующего шага;
- координация работы разных сотрудников (особенно если речь о разных подразделениях);
- функционал "вне процессов" — различные согласования, постановки задач, напоминания, заметки, хранение информации и т.п.
Другими словами, мы можем составить некий общий предполагаемый процесс, который будет снабжен, во-первых, стандартным функционалом для пользователей, во-вторых, на который можно нарастить определенные алгоритмизируемые простые процедуры, которые, в отличие от общего процесса, как раз можно и часто нужно "просчитать" и максимально оптимизировать, а где можно — автоматизировать.
Собственно, это всё, пример описания такого процесса для удобства будет оформлен в виде отдельной заметки.
Начнем с моего любимого вопроса: зачем. Зачем нужно описание процесса продаж (В2В, т.е. когда продает бизнес бизнесу)?
Основная цель — получить некие вехи, промежуточные этапы, по которым можно судить об успешности работы продавцов и тем самым контролировать процесс. Могут быть еще дополнительные цели, например, чтобы поставить работу продавцов в соответствие с процессами других подразделений или чтобы было проще унифицировать работу разных сотрудников, особенно, если они работают недавно (и тут будет законным вопрос — зачем ее унифицировать — но не будем отвлекаться пока что).
Но основная цель, обычно, — контроль.
Естественно, достаточно часто, когда речь идет о продаже серьезных решений, есть соблазн не вмешиваться в работу специалистов по продажам и предоставить их самим себе. Особенно, если они показывают результат.
Однако, в какой-то момент случается так, что результата нет, и тогда хочется разобраться, а что же вообще делалось, раз ничего так и не сделано, — по крайней мере не сделано так, чтобы получить тот самый результат.
И тогда может оказаться, что специалисту по продажам (продавцу, менеджеру по продажам, вице-президенту по продажам и т.п.) очень сложно отчитаться о том, что конкретно вообще было сделано. И у руководства естественным образом может возникнуть желание все-таки контролировать и процесс тоже, а не только результат. Чтобы отрицательный результат не стал сюрпризом к концу отчетного периода.
О разных подходах к описанию процессов напишу отдельно, сейчас рассмотрим процессы с точки зрения начальных событий и развивающихся после этого различных действий.
Предположим, что лиды — это забота маркетинга (вообще-то так и должно быть, в большинстве случаев, за исключением реферальных рекомендаций и личных связей продавцов), тогда начальным событием может быть получение такого лида продавцом от маркетинга.
Что делает продавец в таком случае? Ну, наверное, неплохо бы изучить лид немного подробнее, затем попытаться выйти на контакт — или сразу выйти на контакт, если маркетинг любезно об этом уже договорился (да, так делают, это нормальная практика).
Далее начинаются слабо предсказуемые движения от звонков к встречам, от имейлов к звонкам, от встреч до звонков и имейлов, когда совершенно не факт, что процесс уложится в какой-то понятный алгоритм.
Поэтому обычно в таких случаях говорят о т.н. happy way, т.е. процессе, который идет по "счастливому пути", идеально.
Опять же, зачем, если в реальности он может пойти очень витиевато? А чтобы обозначить те самые вехи. Никто не собирается укладывать В2В-продавца в прокрустово ложе жесткого алгоритма, это вряд ли получится, но хотя бы обозначить вехи — уже можно попробовать.
Получаем, что в реальности продавец делает непонятное количество разной успешности звонков, имейлов, встреч, презентаций и т.п., но мы это отражаем не столько действием, сколько предполагаемым действием и статусом клиента на разных этапах.
Следующая проблема: продавцы склонны завышать ожидания. Чтобы избежать выгорания и упорно делать сложную работу, продавцы вынуждены быть супер-оптимистами, хотя бы формально (неформально они потом могут бухать по вечерам в глубокой депрессии), иначе будет сложно оставаться достаточно настойчивым и продолжать делать свою работу.
Но для трезвого анализа такой настрой не годится, нам нужно четко понимать вероятность заключения сделки.
Стандартный прием, который часто предлагают даже очень (очень, реально) уважаемые агентства, — присваивать некую вероятность на каждом этапе. На глазок.
Понимаю это, когда не выходит сложить статистику. Но сейчас-то со статистикой проблем быть не должно. Можно же посчитать, сколько лидов из состояния А перешло в состояние Б (т.е. т.н. конверсию), отсюда посчитать более-менее реальный прогноз, а не от потолка ставить 50% вероятности всем на этапе коммерческого предложения, к примеру. А может там реально всего 5%, что ж себя обманывать так жестоко.
Т.е. решение понятно — настраиваем отчет и учитываем статистику, а уже отсюда, а не от эмоциональных ожиданий продавцов, делаем прогноз.
Так что с процессом? Получается, что можно сделать что-то вроде образцового алгоритма, который вряд ли повторится в жизни, но который позволит обозначить определенные действия и получать показатели по этим действиям.
Сразу скажу, это не золотой ключик и проблему не решит. Проблему решает качественная продажа, а это — всего лишь один из разновидностей контроля работы, не более того. Но это важно, если руководитель хочет руководить, а не просто слушать отчеты о результатах и в зависимости от успешности ругать или хвалить подчиненных.
Приведу пару примеров. Один случай описан Нилом Рэкхэмом: в компании решили улучшить показатели путем увеличения количества встреч продавцов с потенциальными клиентами. Но результат оказался противоположным: продавцы, вынужденные проводить больше встреч, стали хуже к ним готовиться, им не хватало времени, поэтому встреч стало больше, но сделок, вопреки ожиданиям, — меньше. Не всё решают цифры, цифры могут помочь понять суть, но саму суть при этом игнорировать не следует.
Еще пример: некая компания обнаружила, что наибольшее количество отказов клиентов приходится на конец месяца. Исследование этого феномена вскрыло следующую вещь: продавцы к концу месяца пытались нагнать план, поэтому действовали излишне агрессивно, что давало обратный результат и наоборот, понижало количество сделок. Вот тут как раз цифры дали повод посмотреть, а реальное вникание в проблему натолкнуло на решение: уменьшить отчетный и плановый период для продавцов с месяца до недели, чтобы у них не было соблазна оставлять на конец месяца всю работу.
Вернемся к описанию процесса, к чему мы пришли?
Получается, что описать процесс точно — не вариант. Слишком много непредсказуемых моментов. Можно в "большом" процессе эти моменты запихнуть в т.н. ad hoc подпроцесс (когда просто перечислены действия, но их порядок не регламентирован), можно описать "счастливый" вариант, без требования жестко ему следовать.
Второе в последнее время достаточно популярно. И применяется вместе с управлением кейсами (грубо говоря, кейс — когда мы не знаем точный алгоритм последующих действий, при этом их выбор — на совести исполнителя). Например, предлагается идти "по процессу", но исполнитель может отклониться в любой момент и система автоматизации ему это позволит.
Показатели при этом все равно считываются по действиям, так что можно выбрать ключевые и по ним попытаться увидеть общую картину.
Автоматизация при этом заключается, обычно, в следующем:
- фиксация действий исполнителей;
- выполнение различного рода автоматических скриптов (информирование, формирование документов, составление отчетов и т.п.), сюда же формирование отчетности для аналитики;
- "подсказка" исполнителю следующего шага;
- координация работы разных сотрудников (особенно если речь о разных подразделениях);
- функционал "вне процессов" — различные согласования, постановки задач, напоминания, заметки, хранение информации и т.п.
Другими словами, мы можем составить некий общий предполагаемый процесс, который будет снабжен, во-первых, стандартным функционалом для пользователей, во-вторых, на который можно нарастить определенные алгоритмизируемые простые процедуры, которые, в отличие от общего процесса, как раз можно и часто нужно "просчитать" и максимально оптимизировать, а где можно — автоматизировать.
Собственно, это всё, пример описания такого процесса для удобства будет оформлен в виде отдельной заметки.
No comments:
Post a Comment