Всем привет!
У меня такой вопрос. Заказчик хочет узнать, используют ли его сотрудники внедренную CRM-систему, благодаря которой он надеется увеличить продажи. Но для этого нужно, что бы сотрудники использовали возможности системы: работали по заложенным в систему БП, заполняли важные поля и другое. Вывод необходимо сформировать на основании количественных и качественных (анкета) показателей. Компания работает немного более одного года в системе.
Какие показатели Вы посоветуете использовать для анализа?

Спасибо!

iscrafm , спасибо что заглянули!
Действительно, анкетирование будет использовано в качестве инструмента оценки качественных показателей.
Тем не менее, заказчик хочет также посмотреть на количественные данные.
Я пока придумал следующее (но этого очень мало):
1. Среднее количество активностей (встреч, звонков) в день, которое менеджер регистриет в системе.
2. Среднее количество новых клиентов в неделю, которое он регистрирует в системе.
3. Количество сущностей "продажа", которые созданы не в рамках работы по БП (отслежывается в системе).

Может быть кто-нибудь сталкивался с подобным уже... подскажите, что-нибудь :).

Андрей Ж.
Отчет впечатляет :). Подскажите, какие выводы были сделаны на основании такого отчета?
Но ведь сбор такой статистика это огромная нагрузка на БД и соотвественно снижение производительности системы, нет?

iscrafm
Согласен, 3 допускать нельзя. Но если система изначально была сконфигурирована так, что такая возможность есть, можно использовать это как доказательство того, что БП используются не в полной мере?

FE
FEА зачем собирать статистику? Как это поможет использованию системы? По-моему, если заказчик хочет знать, используется система или нет, достаточно войти в неё и посмотреть работу того или иного менеджера.

Простите, что вы собираетесь анализировать?
Что Вы имеете ввиду под "как это поможет использованию системы?". Если мы увидим, что не заполняются какие-либо важные для принятия решения поля карточки контрагента, внимание клиента будет на это обращено. Если БП используются не в полной мере, об этом тоже будет сообщено клиенту. Это своего рода аудит.
Анализировать буду то, используют ли сотрудники функционал системы на требуемом уровне.

Shuhard
Спасибо что заглянули!
Может быть Вы мне подскажите, каким образом получив информацию по показателям, приведенными Вами, я смогу ответить, что сотрудники используют систему? Сравнить показатели со значениями год назад? Спасибо.

Shuhard
Shuhardв более общем виде расчет ROI для CRM занятие бессмысленное и беспощадное\
Я уже об этом читал :). Хорошо, что в проекте нет такого требования заказчика.

Fitch
Спасибо большое что заглянули и за хорошее предложение! :)

Выскажусь, вначале, в том духе, что не зная бизнеса, который автоматизирует CRM-система, подбирать показатели для ее анализа занятие неблагодарное. В разных бизнесах все может быть по-разному. Так что про бизнес анализируемой компании стоит подробнее рассказать.

Компания специализируется на продажах холодильного оборудования с полным циклом начиная от предпродажного обследования и заканчивая проектной установкой оборудования. Продажи длительные по сроку и сложные. Компания использует CRM на протяжении года.

Да и вообще, главное CRM-стратегия, а CRM-система лишь ее автоматизирует или помогает внедрить – вот от того, что стратегия требует, и «плясать» надо.

Согласен, именно поэтому большинство вопросов в анкете, которую я составил, совмещают как оценку знания и применения методов эффективных продаж, так и использование для этого системы. Анкета во вложении, если кому-нибудь будет интересно. Также может кто посоветует добавить еще какие вопросы в нее.

Если вообще про анализ системы говорить, то естественно начать с активности пользователей в системе.
Я бы даже не со «среднего в день» начал, а с временного анализа: вначале вносили такое количество, сейчас такое.
Далее разбил бы пользователей на группы: богатые-бедные, новички-старожилы (за последнее время, какое - от бизнеса зависит) – получил бы картинку.

Что Вы имеете ввиду под активностью пользователей? Если я правильно понимаю, активность может быть следующего характера:
1. Создание записи в разделе
2. Редактирование записи в разделе.
3. Удаление записи в разделе

Снять статистику по количеству созданных записей просто. А вот по редактированию записи, то есть какие поля редактировались, сколько раз достаточно сложно, без предварительно настроенного логирования изменения.
По каким сущностям Вы бы посоветовали смотреть динамику? Клиенты, задачи, продажи, счета... что еще?

Добавил бы в показатель количество клиентов, с которыми общаются – еще одна картинка. Ну а всякие средние - на закуску.

Это есть :)

Отметил бы количество запланированной активности – хороший показатель по использованию системы. Если люди в системе планируют – значит пользуются.

Спасибо, действительно хороший показатель.

Далее БП продаж. В первую очередь завершенные отрицательно, без продажи. Анализ соотношений завершенных отрицательно и положительно хороший показатель использования системы. Я верю, что есть менеджеры, любую сделку доводящие до продажи – на практике таких не встречал. Если процент нормальный, то неплохо бы качественный анализ провести – что пишут (и пишут ли!) при отрицательном закрытии.

Насколько здесь имеет смысл рассматривать именно количество бизнес-процессов? Я предполагал, что буду рассматривать количество потенциальных сделок созданных всего по отношению к тем, которые доведены до продажи.

Соотношение сделок по БП и без него тоже показатель, как iscrafm сказал – нельзя его игнорировать, значит нужно учесть.

Есть.

Ну и «зависшие» БП. Часто это скрытые проигранные сделки. Но не всегда. Как понять то или не то – от бизнеса зависит. Тем не менее проанализировать их надо: хотя бы понять, на каком этапе зависают...
...
Далее заполнение полей. Не сомневаюсь, что обязательные для заполнения поля есть. Остальные можно разделить на «важные», «желательные» и прочие. Ну и оценить их заполнение: для «важных», у тех, кто стали клиентами должно быть 100%, для желательных – близко к этому.

Ок.

И еще бы один показатель посмотрел: кросс-активности. То есть когда один менеджер в системе регистрирует активность для другого: тот отсутствовал по каким-то причинам, а за него звонок принял другой. И оставил в системе историю. Если такого нет, то я бы вообще бизнес CRM-ориентированным не называл бы. А если есть и часто – система точно работает.
Интересный показатель. Спасибо. Попробую применить.

Забыл анкету прикрепить

2 Fitch
Впрочем, я всего лишь пытаюсь подсказать ответ на вопрос: «используют ли его сотрудники внедренную CRM-систему?». Может в реальности цель другая.
В реальности цели 2, которые я для себя формулировал вопросами:
1. Можно ли считать, что эффективная методика (методика, которая была предложена при бизнес-консультировании) продаж внедрена (используется сотрудниками) в компании?
2. Можно ли считать, что сотрудниками компании используется функционал системы для работы по внедренной методике?
Частью вопросов, как, например, тем же первым, я пытался охватить именно первый пункт, методику без системы (стратегию CRM).

Искренне повеселился, читая представленную Вами анкету. Похоже, вы никогда не работали продавцом?
Рад, что я Вас развесилил :)... я никогда не работал продавцом в компании, которая использует регламенты, воронку продаж и др. Я работаю в проектном отделе, где вся деятельность описывается регламентами: стадии проектов описаны в регламентах, требования к проектной документации описаны регламентами, порядок взаимодействия с клиентом описаны регламентами - могу предположить, что в отделе продаж должен быть такой же порядок. Я не прав?
Кроме того, я склонен рассматривать систему (ее составляющие) как своего рода регламент. Например, если в воронке продаж определены руководством 5 стадий продаж, значит система регламентирует этот вопрос. Если БП продажи предполагает изначально
подготовку ко встречи (сбор материалов о клиенте, выявление направления предположительного интереса), и только потом собственно проведение встречи, значит система опять регламентирует деятельность. Возможно, такая моя (не обязательно правильная) точка зрения поможет Вам понять логику, которой я руководствовался при составлении анкеты.

И не пытайтесь создать уникальную анкету для всех. Анализируйте постепенно .
Думаю многие поняли, что проект с такими задачами для меня первый :). Предложенный мне план проекта упрощенно сводится к следующему:
1. Составляем анкету
2. Составляем список показателей, которые необходимо получить.
3. Проводим анкетирование
4. Получаем данные по показателям
5. Анализируем.
6. Делаем вывод, даем рекоммендации.

При таком плане постепенный анализ не получиться. Будет ли такой план более логичным?
1. Составляем список показателей, которые необходимо получить.
2. Получаем данные по показателям
3. Анализируем.
4. Составляем дополнительный список показателей, которые необходимо получить.
5. Составляем анкету
6. Проводим анкетирование
7. Получаем данные по показателям
8. Анализируем.
9. Делаем вывод, даем рекоммендации.

Уточните разницу между вашим пониманием БП и понятием сделка. Для меня в CRM они синонимы.
Возможно я с Вами соглашусь, что БП именно продаж и сделка (продажа) это синонимы, не не любой БП. Кроме того, когда я говорю про систему, я предполагаю, что БП это заложенный в систему и управляемый ей порядок действий. Тем не менее, БП может существовать и не в заложенном в систему виде, а как регламент (документ).

О том, что некоторые вопросы вызывают улыбку, даже если на первый вопрос ответить «да», я промолчу – не тот форум и не то время, чтобы объяснять.
Продолжают ли они вызывать у Вас улыбку, после того, как Вы теперь знаете также и другую цель анализа (не анализ системы), описанную выше. Если да, лучше не молчите, и выскажитесь, пожалуйста. Мне будет очень полезно понять причину Вашей улыбки :).

2 V.Sopkin
Спасибо за то, что присоеднились :).
Во-первых непонятно, как можно было организовать систему управления, которая позволяет работникам игнорировать установленное программное обеспечение и никто об этом не знает. Любая приличная АСУ должна решать этот вопрос изначально, при проектировании.
Если я Вас правильно понимаю, Вы считаете, что если клиент регистрируется в системе, подразумевается, что мы планируем с ним работать. Соответственно, нужно запретить создание клиентов не в рамках бизнес-процесса. Но ведь это опасно, верно? Что если компания осознает, что существующий БП не эффективен, и инициирует его изменение. Изменение БП в компании можно осуществить очень быстро, создав новый регламент, тем не менее программные изменения могут сильно затянуться, так как сама компания не может конфигурировать систему и должна использовать услуги компании, которая внедряла систему. В этот момент в той компании возможно нет свободных ресурсов. Как тогда поступать? То есть, как учесть возможные изменения в операционной деятельности?
Вторая ситуация. Процессы в компании могут происходить по огромному количеству сценариев. Компания не готова инвестировать большую сумму в вычесление всех этих сценариев и разработку БП по ним. Но, есть сценарии, которые используются наиболее часто, их не много. Вот в разработку этих немногих БП компания инвестирует. Если закрыть другие возможности работы, кроме как по БП, компания не сможет работать. Как поступать в таком случае?

С закртытием отчета очень понравился вариант:).

V.Sopkin
Это автоматизированная СИСТЕМА УПРАВЛЕНИЯ , которая обязана развиваться вместе с предприятием, ориентируясь на изменяющуюся стратегию/тактику бизнеса...Ведь это документооборот, функции, распределение обязанностей, ресурсы (трудовые, финансовые, временные). И программное обеспечение АСУ просто обязано успевать за изменениями бизнеса
Я понял. Какая существующая практика поддержки бизнес-процессов? Опять платить деньги компании, которая внедряла систему, за изменение БП? Или лучше внедрять систему, в которой нанятый и обученный специалист сможет внести изменения?
Что значит огромное количество сценариев бизнес-процесса? Вероятно, это просто возможные варианты реализации бизнес-процесса. Это как изготовление детали по альтернативным технологиям в зависимости от используемого материала, оборудования, инструмента и спец.оснастки. Или определение договорной цены в зависимости от условий оплаты.
Да, это я имел ввиду. Так как тогда поступать компании, которая не готова инвестировать большую сумму в вычесление всех этих вариантов реализации сценариев и разработку БП по ним? Но, есть сценарии, которые используются наиболее часто, их не много. Вот в разработку этих немногих БП компания инвестирует. Если закрыть другие возможности работы, кроме как по БП, компания не сможет работать.

Mainframe_старый
По заполняемости полей - анализ на полноту (отношение сущностям с пустыми полями к общему числу сущностей ) , но тут правило простое, если нужно, чтобы пользователи вели определенные поля, надо их делать обязательными к заполнению.
Обязательные к заполнению поля это поля, без которых дальнейшая работа с клиентом невозможна. Не обязательные к заполнению поля это поля, информация в которых помагает эффективней работать с клиентом - тоже очень важная. Думаю отслеживать заполненность нужно по всем полям в карточке. Как Вы думаете?
Статистика ничего не жрет, если ее выполнять в нужное время, на клиенте или просто данных немного, а сервер хороший.
т.е. это не проблема.
Считаете ли Вы, что при разработки системы, также необходимо сразу определять, будет ли клиент платить за отслеживание эффективности использования системы, и если да, продумывать заранее вместе с ним показатели, по которым будет собираться статистика (не касается тех показателей, по которым можно собрать статистику без постоянного логгирования)?
Вопрос 2 - про эффективность использования - несколько иная задача. Но вам же не ее надо решать
Можно немного подробней? Что означает, например, система используется не эфективно?

2 Fitch
Ясно! Спасибо большое! Удачи! :)

2 popov19
А как он может понимать? :)... если этот вопрос интересует руководителя, у которого в подчинении 500 человек, 30 из которых должны пользоваться системой, и ему говорят , что системой пользуются, как он может понимать , правду ли ему говорят?