Все о Microsoft Dynamics CRM: Построение бизнес-процесса автоматизации ведения Возможной сделки (часть 2)

[Blog bot]

Источник: http://ms-dynamics-crm.com.ua/2012/0...rtunity-part2/
==============

Часть 2. Разработка бизнес-процессов

Наконец-то появилось немного свободного времени (и как всегда – в выходные 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 по умолчанию ответственным назначает автора сделки).



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



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

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



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





Источник: http://ms-dynamics-crm.com.ua/2012/0...rtunity-part2/