Вспомним наши соображения по реализации (см. часть 1): нужные данные аккумулируются в Возможной сделке и их подсчет проводим разово, когда это необходимо.

Такими данными являются даты завершения этапов продаж в воронке:

• дата завершения этапа Встреча;
• дата завершения этапа Переговоры;
• дата завершения этапа Договор;
• дата завершения этапа Счет;
• дата завершения этапа Отгрузка.

Дата завершения этапа Реализация совпадает с фактической датой закрытия успешной сделки. Фактическая дата закрытия также работает для отмененных или потерянных сделок.

Шаг первый. Добавляем новые поля (5 полей типа Дата) в сущность Возможная сделка.

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

Шаг третий. Создаем новую сущность – Оценка эффективности – и для нее создаем новые поля и конструируем форму. Вот так она может выглядеть:

Шаг четвертый. Пишем несколько простых скриптов, обеспечивающих правильное поведение формы при ее заполнении пользователем.

Шаг пятый и самый ответственный. Разрабатываем и отлаживаем в web интерфейсе REST запросы, которые позволят нам получить из CRM данные по сделкам в соответствии с заданным условием фильтрации.

Шаг шестой. Добавляем в страницу Оценки эффективности сценарий асинхронного запроса и подсчета количества сделок / расчета коэффициентов эффективности.

Шаг седьмой. Тестируем новый функционал CRM и наводим необходимый лоск. J

Несколько замечаний

Подсчет количества сделок на разных этапах запускается по нажатию кнопки Подсчитать на ленте формы Оценка эффективности.

Расчет коэффициентов эффективности возможен только при наличии подсчитанных количественных показателей сделок; он запускается при нажатии на кнопку KPI.

Так как изменить даты создания сделки, перехода на следующий этап, закрытия сделки в общем случае невозможно, то логика работы с Оценкой эффективностью банальна до безобразия:

1)       Создаем Оценку эффективности за предыдущий период для заданного пользователя.

2)       Жмем последовательно на кнопки Подсчитать и KPI.

3)       Сохраняем созданную Оценку.

Все поля с показателями доступны только для чтения, что исключает возможность несанкционированного их редактирования пользователем.

Доступ к оценке эффективности следует предоставить:

• По чтению — пользователю с ролью безопасности Продавец.
• По созданию/чтению/редактированию/удалению — пользователю с ролью безопасности Руководитель.

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

Элементарные расчеты показывают, что ошибка расчета квартальной оценки при средней продолжительности сделки в 1 месяц составит примерно 20%, при средней продолжительности в 20 дней — 17%, при средней продолжительности в 10 дней — 10%. В то же время ошибка годовой оценки общей эффективности менеджера для сделки в 1 месяц составит не более 7,5%.

И мы помним, что такие оценки эффективности нужны в первую очередь не для точной количественной оценки, а для качественного анализа динамики (или тенденций) процесса и сравнительного анализа субъектов оценки (то бишь работы команды менеджеров).

Удачи вам в оценках!

Sergiy.Yezhov@gmail.com

Дополнительные материалы:

Оценка эффективности с помощью CRM — часть 1

Оценка эффективности с помощью CRM — часть 2

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

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

Такая активность менеджера приносит свои плоды, и его ценность для компании неизменно растет. Что показывает нам следующий график. Руководителю подразделения будут интересны не только абсолютная ценность менеджера в деньгах (т.е. окупает ли себя менеджер), но и сравнительный анализ ценности менеджеров относительно друг друга. Становится сразу видно, кто начал лениться или у кого идут дела не очень и, возможно, менеджеру требуется помощь либо переориентация на другой сегмент рынка / клиентскую аудиторию. Напомню, что ценность менеджера рассчитывается как усредненная по кварталу месячная прибыль (или заработок менеджера). В части первой статьи я назвал этот показатель Стоимостью менеджера; более правильным названием будет все же Ценность менеджера.

Следующий график еще более интересный. На нем построены три кривые: количественная оценка эффективности, баланс открытых сделок и финансовая оценка эффективности.

Синий график показывает, какой процент (если умножить на 100%) зарегистрированных в CRM сделок доводится до успешного завершения. А красный график добавляет информации о денежной составляющей сделок. Наконец, зеленая кривая иллюстрирует потенциал компании в перспективе (т.е. зеленый график «подкармливает» синий и красный цвета).

Все три графика нужно анализировать совместно. Вы можете заметить, что эффективность работы компании со сделками неуклонно растет и во втором квартале уже 46% сделок становятся результативными. В то же время менеджеры успешно заполняют воронку продаж свежими сделками, поэтому во 2 квартале баланс открытых сделок превысил единицу (суммарное число сделок с завершенными встречами и переговорами уже на 11% больше количества заключенных сделок). В то же время компания хорошо сработала в 1 квартале (см.красный график). Несмотря на 36%-эффективность «работы» воронки продаж по количественному «перемалыванию» сделок, финансовая эффективность составила 82%. Это говорит о наличии нескольких крупных сделок, которые дали основной прирост в показателе финансовой эффективности. Во втором квартале, несмотря на количественный рост сделок в работе, показатель финансовой эффективности снижается – единичные крупные сделки отсутствуют.

Заключительный график представляет собой диаграмму областей с накоплением. Кроме того, что этот график показывает коммерческую активность подразделений в сравнении, дополнительно он позволяет визуально оценить «нацеленность» подразделений на деньги. Чем больше красного, тем больше денег подразделение приносит компании. Усреднение может проводиться по любому временному периоду: месяцу, кварталу, году.

Вы можете построить и другие подобные графики; все зависит от ваших потребностей и вашего умения обращаться с мощным инструментарием, который предоставляет нам Microsoft Dynamics CRM. Единственное, никогда не стоит забывать, что платформой для расчета показателей эффективности (и построения красивых графиков) служит скрупулезное накопление исходных данных. А заносят эти данные менеджеры, поэтому стройте, пожалуйста, свои бизнес-процессы и правила работы в компании такими, чтобы максимально стимулировать пользователей работе в CRM! Успехов вам!

Дополнительные материалы:

Оценка эффективности с помощью CRM — часть 1

Оценка эффективности с помощью CRM — часть 3

Постановка задачи

Цель

Научить CRM оценивать эффективность коммерческих специалистов (или менеджеров) на основе существующих данных.

Исходные данные

Есть стандартный интерфейс для работы с целевыми показателями.

Имеются работающие бизнес-процессы (БП), автоматизирующие ключевые этапы коммерческой деятельности фирмы.

Что требуется

Создать механизм расчета и наглядную визуализацию показателей эффективности.

Отступление, экономящее время

Данная статья ориентирована, в первую очередь, на внедренцев CRM и бизнес-аналитиков, занимающихся мониторингом / анализом коммерческой деятельности. Здесь не будет примеров кода и описаний алгоритмов. Поэтому разработчики и писатели кода, которым не интересны и не понятны внутренние пружины бизнеса, могут сэкономить свое время, отложив чтение до лучших времен .

Второй нюанс. Достаточно часто в реальной жизни встречается вот такая позиция руководителя: «Предложите мне 3-5 ключевых показателей (кроме оборота/прибыли, которые я и так знаю), по которым я смог бы оценивать свой бизнес в целом». На самом деле, методики расчета таких показателей известны давно: это и KPI, и система более высокого уровня BSC, и показатели GRI социальной направленности бизнеса… Проблема же заключается в том, что для начала нужно иметь базис, на котором можно организовать расчет выбранных показателей эффективности. Вы или ваш клиент приобрели CRM – отлично! Но это только одно из обязательных условий… Теперь нужно начать копить и складывать в хранилище необходимые данные (об их полноте, объективности, актуальности и постоянном внесении / обновлении я даже и не говорю). Если ваша компания использует CRM для фиксации истории взаимоотношений с клиентами, а данные по сделкам: сроки, доход и прибыль в CRM не заносит — то эта статья не для вас. Нельзя из ничего сделать полезную вещь, даже и не пытайтесь .

Нюанс третий. Где и когда собственно возникает потребность расчета показателей эффективности? Ответ лежит на поверхности: расширенные системы показателей (кроме анализа дохода / прибыли) востребованы, в первую очередь, в компаниях, где влияние менеджера на конечный результат (деньги компании) достаточно велико. Т.е. сам менеджер, с его компетенциями, лояльностью к компании и сиюминутными настроениями, становится инструментом для совершения продаж. Естественно, грамотный руководитель, должен следить за своим инструментом и контролировать его производительность J Чтобы затем вовремя вмешаться, подкорректировать либо заменить на новый. Отсюда понятно, что основная область применения системы показателей — это компании, где доля активных продаж высока. Если же ваша компания продает товары по телефону / Интернету или в торговом зале, то, наверное, эта статья не для вас, пусть даже вы и используете CRM. Просто для оценки бизнеса будет вполне достаточно бухгалтерской программы, а модуль Маркетинга в CRM в этой статье не рассматривается

Выбор показателей эффективности

Отличная поговорка «Как корабль назовете, так он и поплывет» позволит нам быстро и системно решить эту важную задачу выбора.

Целевое назначение показателей (корабль) — оценка эффективности работы менеджера и отдельного подразделения. 1-3 главных показателя, 2-3 второстепенных для углубления и детализации. Название показателей должно быть емким и отражающим их суть.

Теперь о содержании самих показателей (море). Поскольку мы используем классическую воронку продаж, то естественным было бы оценивать эффективность работы менеджера по горловине и горлышку воронки, т.е. сколько было на входе и что стало на выходе – с деньгами и с количеством сделок.

Что лучше использовать: денежные или количественные показатели?

Выбор зависит от внутреннего механизма продаж, действующего в компании.

Первое. Если один менеджер отвечает за конкретный, четко очерченный участок (будь то рынок, бренд или регион) то, как правило, существует взвешенная стоимость одной сделки, к которой тяготеют все продажи такого менеджера. Очень редко можно встретить менеджера, который с одинаковым старанием продает и дешевые коробки, и дорогие решения, да еще и показывает примерно одинаковое распределение общего дохода по этим двум группам продуктов.

Отсюда следует, что в достаточно широком временном интервале можно спрогнозировать выход в деньгах (доход), если умножить среднюю стоимость сделки на коэффициент перехода от входа к выходу.

Второе — субъективный фактор. Если менеджер обычно завершает этап переговоров по сделке за 3 дня, то будьте уверены, что эта привычка распространяется на все сделки: мелкие, средние и крупные. Мне могут возразить и сказать, что вот уж длительность этапа заключения договора точно зависит от стоимости сделки: чем договор дороже, тем его тщательнее и дольше проверяет и клиент, и менеджер. Наверное, не соглашусь, потому что вижу, что во многих бюрократических конторах срок прохождения договора по всем инстанциями одинаков и для закупки офисной бумаги, и для приобретения престижного автомобиля.

Рекомендации

Используйте количественные показатели для оценки эффективности типовой работы (типовых операций) и там, где исходные данные сгруппированы возле среднего значения.

Используйте финансовые показатели для оценки общей эффективности разнородной работы либо для оценки нескольких слабо- и несвязанных бизнесов.

Показатели эффективности и воронка продаж

На рис. ниже я привел классическую воронку продаж, которую строит CRM в соответствии с рассмотренным в предыдущей статье алгоритмом.

Формулы для расчета показателя общей эффективности будут выглядеть следующим образом:

  ,

где  — финансовый показатель эффективности,  — фактически полученный доход от завершенной i-й сделки,  — прогнозируемый доход от j-й сделки, N — количество успешно завершенных сделок, K — количество созданных (зарегистрированных в CRM) сделок.

  ,

где  — количественный показатель эффективности,  — количество успешно завершенных (выигранных) сделок,  — созданных (зарегистрированных в CRM) сделок.

Хороший продавец знает, что наиболее важными являются первые этапы продажи: встречи / обсуждения, переговоры и, наконец, заключение сделки. Следующие этапы: счет, отгрузка, реализация, в большинстве своем, носят технический характер и требуют простого соблюдения установленных инструкций либо грамотной организации проекта.

Руководителю, чтобы понять «узкие» места своего продажного офиса, в первую очередь следует анализировать именно первые три этапа воронки активных продаж и рассчитывать количественные показатели эффективности встреч, эффективности переговоров и эффективности заключения сделки.

Далее, можно оценить «запас прочности» коммерсанта, рассчитав отношение количества сделок на этапе встреч и переговоров к количеству заключенных сделок, находящихся в работе (этапы Договор, Счет и Отгрузка). Этот показатель можно еще назвать балансом открытых сделок.

Наконец, хочется контролировать, что все продавцы приносят компании деньги. Зная точку безубыточности (или минимум прибыли, которую должна зарабатывать компания в месяц), можно рассчитать для каждого менеджера его минимальный план по прибыли. Усреднив все заработанные менеджером деньги по времени и приведя их к месячному отрезку, мы получим так называемую стоимость менеджера, которую интересно будет сравнить с месячным планом по прибыли.

Итак, вот список наших показателей эффективности

Задание на доработку CRM

Показатели выбраны, теперь дело за малым — определить, где в CRM брать исходные данные для расчета? Ниже я предложу лишь один из подходов к реализации методики расчета показателей эффективности. Мои соображения были следующими:

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

Во-вторых, реализация любых динамических счетчиков (для подсчета количества сделок) сопряжена с тщательным анализом всех возможных случаев, включая отмену сделки и повторную ее активацию. Следовательно, необходимо просто записывать в сущность Возможная сделка только необходимые данные, а уж затем разово их подсчитывать.

В-третьих, где-то нужно хранить рассчитанные показатели и откуда-то нужно запускать подсчет возможных сделок на разных этапах продаж. Следовательно, нужна новая специфическая сущность, назовем ее Оценка эффективности.

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

Дополнительные материалы:

Оценка эффективности с помощью CRM — часть 2

Оценка эффективности с помощью CRM — часть 3

Однако, используя функции табличного процессора Microsoft Excel 2010 (на других версиях офиса не проверялось), можно легко ликвидировать этот недостаток.

Ниже в картинках показан способ экспорта табличных данных (работает не только для метаданных, но и для обычных представлений CRM).

1. Открываем Решение по умолчанию: Параметры / Настройки / Настроить систему.

2. Копируем в буфер обмена строку адреса (URL).

3.  Запускаем Excel и переходим на страницу Данные. Жмем кнопку Из Интернета.

4. Excel автоматически запускает Построитель web-запроса и копирует в строку адреса URL вашего сервера CRM online. Если все прошло успешно, то вы получаете стандартный запрос на ввод своего логина и пароля.

5. После входа вы окажетесь на привычной головной странице CRM. Далее, вам нужно перейти на страницу Решения по умолчанию выбранной сущности. Если вы это сделаете обычным способом, то Решение по умолчанию откроется в новом окне, и ничего импортировать не получится. Здесь нам как раз и пригодится скопированный в пункте 1 адрес.

6. На открывшейся странице Решения по умолчанию раскройте искомую сущность и перейдите на страницу Поля. Теперь нужно указать Excel, какие данные ему загрузить из web-страницы формы. Для этого служат значки в виде желтого квадрата с черной стрелкой. Если значков не видно, то перещелкните кнопку, показанную на рис. ниже.

7. Выберите таблицу с метаданными и нажмите в нижнем правом углу кнопку Импорт. Да, перед нажатием на кнопку Импорт желательно на странице Excel выбрать ячейку, с которой начнется «заливка» данных (импорт выполняется слева-направо сверху вниз).

8. Если вы все сделали правильно, то в Excel будут загружены все табличные данные с текущей страницы формы. Если страниц несколько — переходите на следующую и повторяйте операцию.

Например, поле Потенциальный клиент в Возможной сделке может содержать идентификатор записи типа Организация и типа Контакт. Если нажать на кнопку поиска в этом поле, то CRM предложит нам определиться с типом записи:

Такая, безусловно, удобная функциональность вносит определенные проблемы при разработке бизнес-процессов.

Рассмотрим это на примере обработки экземпляра Возможной сделки (ВС) в бизнес-процессе (БП).

Задача

Обеспечить хранение в ВС имени старого потенциального клиента. Т.е. при выборе нового потенциального клиента, данные о предыдущем клиенте должны сохраняться.

Примечание: задача выдумана от начала и до конца и не имеет ничего общего с реальной функциональностью J.

Логика

Напишем БП, который будет срабатывать на изменение поля Потенциальный клиент (событие OnChange).

Так как срабатывание произойдет ПОСЛЕ сделанных изменений, то потребуется 2 кастомных поля для хранения данных о клиентах.

Первое кастомное поле (CurrentClient) дублирует значение поля Потенциальный клиент.

Второе кастомное поле (OldClient) содержит данные о старом Потенциальном клиенте.

При обнаружении события OnChange на поле Потенциальный клиент:

1)       Переписать значение из CurrentClient в OldClient

2)       Переписать значение из Потенциальный клиент в CurrentClient

Реализация

Первая трудность, с которой мы столкнемся, — это невозможность создать кастомное поле типа Клиент, которое позволяло бы записывать в него и Организацию, и Контакта. Вы можете создать поле типа Поиск либо для Организации, либо для Контакта.

Ок, продублируем и создадим CurrentOrganization, CurrentContact, OldOrganization, OldContact.

Вторая трудность: как распознать на этапе отработки БП, в какое из кастомных полей писать значение поля Потенциальный клиент? Ведь БП не содержит в своем функционале определение типа записи…

Решение достаточно простое: использовать в БП динамические значения. Дело в том, что динамические значения полей точно так же не имеют объединяющего поля Клиент и, соответственно, явно разделяют типы записей Организация и Контакт.

Ну вот, теперь достаточно добавить в БП шаг с проверкой условия:

Как и следует ожидать, CRM при использовании динамических значений выполняет операцию приведение типа поля Потенциальный клиент к типу Организация или к типу Контакт (в зависимости от того, какое динамическое значение выбрано). Операция приведения к типу даст null для поля несоответствующего типа, поэтому указанное выше условие вернет false, если мы попытаемся сравнить поле Потенциальный клиент (в котором указан Контакт) с динамическим значением
ВС→Потенциальный клиент (Организация).

PS. Не мешает еще проверить условие: ВС→Потенциальный клиент содержит данные. Иначе вы будете сравнивать null c null и получите в условии выше результат true.

Наконец-то появилось немного свободного времени (и как всегда – в выходные L), чтобы выполнить данное в прошлой статье обещание: рассказать о собственно разработке бизнес-процессов (БП) для автоматизации сделки. Итак, приступим…

Создание нового решения

Для написания БП нам понадобится настроить несколько сущностей: изменить существующие поля. Такую кастомизацию лучше всего выполнять в отдельном решении. Что такое Решение и как с ним работать – отдельная тема. И я надеюсь, вы ее уже освоили.

Создадим новое решение с именем Automation (отображаемое имя Автоматизация сделки).

и включим в него две сущности: Возможную сделку и Задачу.

Кастомизация сущностей Возможная сделка и Задача

Для реализации БП автоматизации потребуется легкая настройка полей сущностей Возможная сделка и Задача.

Как было рассказано в первой части статьи, одной из целей автоматизации является построение воронки продаж по этапам сделки. Поэтому нам необходимо поле, в котором будет храниться название этапа Возможной сделки. Используем для этого строковое поле StepName сущности Возможная сделка. Мне не очень нравится отображаемое имя этого поля: Фаза конвейерной обработки – не очень вразумительно выглядит на диаграммах. Поэтому я сразу переименовываю его в Этап БП.

Следующее изменение касается поля Вероятность. В соответствии с идеологией автоматизации сделки ее вероятность теперь определяет сам БП, а не пользователь. Поэтому мы должны запретить доступ пользователей к полю Вероятность. Это можно сделать, например, следующим образом: удалить поле с формы сущности Возможная сделка и поместить поле Вероятность в верхний колонтитул формы.

Сохраните сделанные изменения.

Еще одна легкая кастомизация коснется сущности Задача. Еще раз обратимся к предыдущей части статьи и вспомним основную идею автоматизации: строить логику обработки на основе распознавания факта завершения задачи. Поэтому нам потребуется простой и удобный механизм выделения из всего множества задач тех, которые обслуживают автоматизацию Возможной сделки. Я использую для этого два поля Категория и Подкатегория сущности Задача. Эти поля служат для классификации задач пользователя и, как правило, самими пользователями не используются. Если же эти поля нужны вашим пользователям – создайте пару новых полей.

Откройте форму сущности Задача в редакторе Решения и удалите с формы два поля Категория и Подкатегория (чтобы исключить возможность редактирования этих полей пользователями). Поместите эти поля в нижний колонтитул.

Сохраните выполненные изменения на форме.

Опубликуйте все настройки.

У нас все готово, чтобы начать разрабатывать БП.

Общие сведения о БП

Я буду считать, что вы уже знакомы с технологией бизнес-процессов и теми инструментами, которые дает нам CRM в плане разработки БП. Поэтому описание ниже не будет содержать «разжевывание» интерфейса Конструктора бизнес-процессов. Если же с этим возникнут проблемы – почитайте встроенную справку по CRM.

Всего мы создадим 5 БП: 4 для Возможной сделки и 1 для Задачи. Назовем их следующим образом:

• Движение сделки по этапам (Возможная сделка).
• Отслеживание задачи автоматизации (Задача)
• Отслеживание изменения состояния (Возможная сделка)
• Оповещение ответственного за сделку (Возможная сделка)
• Начальная инициализация сделки (Возможная сделка).

В принципе, из названий БП уже ясно, для каких целей эти бизнес-процессы предназначены. Начнем с самого простого БП.

Начальная инициализация Возможной сделки

Когда сделка создается, нужно установить начальное значение этапа БП в поле Этап БП.

Небольшое отступление. При построении диаграммы Воронка продаж CRM использует сортировку строковых полей по алфавиту. Мы помним, что наши этапы автоматизации сделки звучат следующим образом: Встреча, Переговоры, Договор, Счет, Заказ и Реализация. Очевидно, что CRM их отсортирует совершенно не в том порядке, как указано выше. Поэтому использовать нужно следующие слегка модифицированные названия:

1 Встреча

2 Переговоры

3 Договор

4 Счет

5 Заказ

6 Реализация

Теперь сортировка результатов запроса будет выполняться правильно.

Вот как будет выглядеть БП инициализации:

Задаем условие запуска автоматического БП: Создание записи и создаем один единственный шаг БП: Обновить запись.

Нажимаем кнопку Задать свойства и редактируем поля сущности Возможная сделка, как указано ниже:

Сохраняем созданный БП.

Вы можете проверить работу созданного БП. Для этого активизируйте БП и создайте новую Возможную сделку. Теперь, используя расширенный поиск, задайте условие выборки Возможных сделок: Этап БП = 1 Встреча. CRM должна найти только что созданную вами возможную сделку.

Вы также можете посмотреть журнал отработки БП в Системных заданиях CRM.

Движение сделки по этапам

Это самый главный БП автоматизации ведения сделки. Его логика основана на следующих соображениях:

• БП запускается при обнаружении изменения значения поля Этап БП.
• БП устанавливает вероятность сделки в зависимости от заданного этапа БП.
• БП создает задачу для менеджера. Содержание задачи определяется заданным этапом БП.
• БП выполняет другие необходимые действия в зависимости от значения поля Этап БП.

Настраиваем БП:

Разобьем весь БП на 7 этапов.

Этап 0. Первый (Этап 0) выглядит следующим образом:

На данном этапе мы останавливаем обработку, если обнаруживаем недопустимые «вхождения» в БП: мы не обрабатываем уже закрытые сделки и не обрабатываем сделки, которые были неправильно инициализированы (т.е. не содержат значения в поле Этап БП).

Этап 1. Обработка этапа Встреча

Этап Встреча распознаем путем анализа значения поля Этап БП сущности Возможная сделка. Если обнаружен переход на этап Встреча (в частности, это происходит сразу же после завершения БП Начальная  инициализация сделки, где устанавливается значение поля Этап БП = 1 Встреча).

Логика этапа выглядит следующим образом:

Для создаваемой Задачи необходимо установить поля:

Тема: «Встретится с клиентом…»

Описание: краткая инструкция по действиям пользователя.

Ответственный: используйте динамические значения, чтобы установить это поле равным Ответственному за сделку.

Срок: используйте динамические значения, чтобы установить это поле равным 1 день после времени процесса выполнения.

Категория: «Автоматизация» — это значение будет использоваться в дальнейшем для выявления задач, созданных в БП автоматизации.

Подкатегория: «Встреча» — это значение будет использоваться в дальнейшем для распознавания этапа БП = Встреча.

Обновляем сущность Возможная сделка, устанавливая значение поля Вероятность = 20%.

Сохраняем сделанные изменения.

Этап 2. Переговоры

Логика БП:

Аналогичным образом описываем этапы 3-6. При необходимости добавляем логику и действия в этапы БП (например, отправку сообщений электронной почты).

Отслеживание задачи автоматизации

Еще один важный БП в автоматизации возможной сделки. Этот БП основан на отслеживании состояния Задачи. Логика БП:

• если Задача успешно завершена – перевести Возможную сделку на следующий этап;
• если успешно завершена Задача на последнем этапе автоматизации сделки – закрыть Возможную сделку с состоянием Выигрыш.

Открываем конструктор БП и создаем новый БП с именем Сделка: Отслеживание задачи автоматизации. Не забываем указать, что данный БП относится уже не к Возможной сделке, а к сущности Задача. Условием запуска данного БП устанавливаем значение Изменение состояния записи.

Как обычно, вначале отсекаем все «неправильные вхождения» в БП. Для этого проверяем, что Задача действительно относится к сущности Возможная сделка: поле В отношении Задачи должно содержать ссылку на сущность типа Возможная сделка. Если Задача ссылается на сущность другого типа, то проверка условия, показанного ниже, даст ложный результат:

Теперь, когда мы уверены, что поле В отношении имеет валидную ссылку, мы можем без проблем работать с полями Возможной сделки (на которую ссылается Задача).

Логика «отсечения» будет выглядеть следующим образом:

Осталось только добавить условие, которое позволит нам обрабатывать только завершенные Задачи, созданные ранее в процессе выполнения БП Движения сделки по этапам. Это простое условие вида:

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

В сущности Возможная сделка устанавливаем значение поля Этап БП.

На последнем этапе закрываем сделку с состоянием Выигрыш:

Сохраняем созданный БП.

Отслеживание изменения состояния

Этот БП придаст законченности нашей автоматизации ведения сделки. Его назначение – предусмотреть и правильно обработать завершающие действия пользователя по работе со сделкой.

Во-первых, пользователь может захотеть закрыть сделку на любом этапе БП.

Во-вторых, пользователь может отменить сделку.

В-третьих, пользователь может захотеть повторно открыть ранее закрытую сделку.

Во всех случаях, процесс автоматизации должен завершиться/начаться заново корректно, а это значит, что в полях Этап БП и Вероятность сущности Возможная сделка должны быть установлены правильные значения:

• Этап БП = Завершено, Вероятность = 100% — после закрытия сделки (не важно, ее закрыла CRM или сам пользователь)
• Этап БП = Потеряно, Вероятность = 0% — для отмененных сделок.
• Этап БП = 1 Встреча – для заново открытых сделок (для таких сделок не выполняется созданный ранее БП Начальной инициализации).

БП создается для сущности Возможная сделка, условие запуска – изменение состояния записи.

В БП следует проверить состояние записи и написать логику для состояний Реализовано, Потеряно и Открыта.

Во многих фирмах факт завершения или отмены сделки должен докладываться «наверх», вышестоящему руководителю. Вы можете добавить соответствующий шаг БП в свою логику. Не мешает также «привязать» отправку сообщения к доходу сделки. Например, сообщение руководителю отправляется только в том случае, если предполагаемый доход потерянной сделки больше 100 000 у.е. Как запрограммировать отправку сообщение – показано ниже.

Оповещение ответственного за сделку

Данный БП важен для фирм, в которых сделки распределяются между менеджерами их руководителем. Пользователь CRM должен своевременно узнать, что ему назначена в работу Возможная сделка. Это оповещение легко организовать путем отправки соответствующего электронного сообщения назначенному ответственному.

Нужно также предусмотреть, чтобы сообщение не отправлялось автору (создателю) Возможной сделки. Если этого не сделать, то при создании сделки ее автор всегда будет получать сообщение о назначении его ответственным за сделку (CRM по умолчанию ответственным назначает автора сделки).

Логика БП будет выглядеть следующим образом:

На этом все. Вам осталось активизировать все созданные ранее БП и проверить их работу.

А в итоге вы сможете пользоваться вот такой красивой диаграммой воронки продаж:

В заключении систематизируем понимание работы БП автоматизации возможной сделки:

Сегодня мы поговорим о правильном построении бизнес-процессов (БП) в CRM.

Наиболее известный из них – это автоматизация ведения Возможной сделки. Суть БП заключается в разбивке процесса продажи на несколько этапов, отличающихся вероятностью осуществления сделки.

В Интернете можно найти некий классический подход в построении БП сопровождения сделки в CRM. Обычно выделяют 6 этапов БП: Встреча (10%), Переговоры (20%), Договор (50%), Счет (70%), Заказ (90%), Реализация (95%). В скобках указана вероятность реализации сделки на каждом из этапов. Конкретные значения, естественно, целиком зависят от специфики бизнеса. Например, в нашей компании принято считать, что заключение договора – это еще полдела: ведь заказчик может заплатить не все деньги или вообще расторгнуть договор из-за отсутствия финансирования (с гос.структурами сегодня это происходит все чаще).

Для чего нужен этот БП в CRM?

• Во-первых, он позволяет построить воронку продаж, а значит – использовать общепринятые и общеизвестные методы анализа эффективности работы ваших коммерсантов, а также увидеть узкие места в активных продажах. Анализу воронки продаж в CRM я посвящу отдельную статью.
• Во-вторых, этот БП позволяет рассчитать взвешенный доход, который может получить ваша фирма.

Можно использовать совершенно простую формулу для расчета взвешенного дохода сделки:

Взвешенный доход сделки = Предполагаемый доход х Вероятность.

Теперь, чтобы посчитать общий взвешенный доход фирмы, нужно просуммировать взвешенные доходы по всем этапам и по всем сделкам.

• В-третьих, БП позволяет систематизировать работу менеджеров и помочь им «не забыть» выполнить определенные действия, определяемые стандартами коммерческой деятельности.

Естественно, все эти преимущества реализуются в CRM с помощью стандартного функционала БП. Кстати, не нашел ни в одном официальном руководстве Microsoft описания построения БП автоматизации ведения сделки. Если кто знает – где таковое «обитает», просьба дать знать J

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

Циклом ожидания называют процедуру, в которой CRM периодически (с только ей известной частотой) проверяет выполнение заданного условия (например, изменилось ли значение в некотором поле конкретной записи). Если факт выполнения условия зафиксирован, то CRM продолжит выполнение БП. Т.е. получается, что CRM «тормозит» на каждом цикле ожидания в БП.

В результате процессор сервера «нагружается» задачами проверки некого заданного условия. А представьте, если в вашей фирме одновременно «крутится» больше тысячи открытых сделок? Это сколько же будет «подвисших на ожидании» процессов? А если аналогичных БП несколько?

Возможно, вычислительной мощности сервера вполне хватит, чтобы успевать выполнять все порученные ему задачи, но приходится надеяться еще и на то, что код обслуживания системных и пользовательских процессов написан должным образом, чтобы случайно «не подвесить» всю систему в ожидании. Иначе ждать завершения БП будете не вы один, а еще и все ваши коллеги…

Следует также подумать о случае, когда вы что-то делаете с записью, в то время как на ней «крутится» цикл ожидания. Что будет с БП, если вы возьмете и удалите запись? Или измените значение в отслеживаемом поле? В общем, вопросов будет больше, чем ответов на них…

Поэтому я люблю завершенные процессы без циклов ожидания. Вот на базе них мы и построим БП автоматизации ведения Возможной сделки.

На рисунке ниже схематически показана типовая схема работы CRM при выполнении БП.

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

Сам же БП строится на основе использования задач. На каждом этапе БП менеджеру ставится задача. Как только менеджер отмечает задачу как выполненную, CRM переводит сделку на следующий этап (см. рис. ниже).

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

Как все это реализовать стандартным функционалом БП в CRM, поговорим во второй части.

Resco MobileCRM Studio

Resco MobileCRM Studio – это платформа для разработки, которая помогает разрабатывать мобильные приложения, используемые как дополнения к Microsoft Dynamics CRM.
Resco MobileCRM Studio полностью интегрируется в среду Microsoft Visual Studio и дает возможность разрабатывать мобильные приложения для устройств с Windows Mobile.

Конкурентные преимущества

• Платформа для разработки
• Лицензионная политика включает беспошлинное распространение мобильных приложений
• Ребрендинг позволяет предлагать мобильное приложение с названием компании клиента

Современный пользовательский интерфейс

Достаточно посмотреть примеры интерфейса

Видео-обзор приложения, разработанного с помощью Resco MobileCRM Studio

Интеграция с бэк-офисом

Клиентское приложение, разработанное в Resco MobileCRM Studio, работает в автономном режиме и использует локальную базу данных MS SQL Server Compact Edition. Интеграция с бэк-офисом осуществлена через Microsoft Dynamics CRM Web Services.

Настройка

Resco MobileCRM Studio  предоставляет наиболее важные модули Microsoft Dynamics CRM в 3 слоях – Data Layer, Synchronization Layer и Data Presentation (UI) Layer. Так как все слои снабжены   исходным кодом на C#, то возможна полная настройка, а также могут быть добавлены новые модули и функциональность. Data и Synchronization Layers используют Microsoft Dynamics CRM SDK, предоставляя стандартизированную платформу  разработки для интеграции данных. Data Presentation Layer реализован через компоненты пользовательского интерфейса из пакета Resco MobileForms Toolkit, который входит в лицензию.

Подробный обзор можете просмотреть по это ссылке, а так же ознакомиться с условиями лицензирования

За этот год мы многому научились, многое попробовали, но много чего еще осталось сделать и чему научиться!

В следующем году мы будем стараться наполнять наш блог полезными статьями, советами, примерами для вас. Планов громадье! Пишите ваши предложения нам, что вам было бы интересно, будем рады научиться чему-нибудь и у вас.

Здоровья, счастья и удачи вам в Новом 2010 году!

До связи!