Дипломная работа: Разработка модуля работы с музейными волонтёрами на базе CRM “1C-Битрикс: Enterprise” на примере ГМИИ им. А. С. Пушкина

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

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

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

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

Экстранет - расширение корпоративного портала, которое предоставляет специфичные права на просмотр и редактирование информации в BitrixCRM доверенным внешним контактам, не являющимися сотрудниками.

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

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

Календарь - инструмент для управления расписанием и событиями в рабочей группы. Особенности экстранет-групп позволяют создавать только общие календари, которые будут доступны для всех пользователей в группе. Этот инструмент удобен для составления расписания мероприятий и приглашения волонтёров на новые задачи.

Введены служебные названияролей, описанных в бизнес-требованиях:

“requester” - роль кандидата в волонтёры, отправляющего заявку на волонтёрство. Роль не имеет доступ в экстранет Битрикса;

“volunteer” - волонтёр, имеющий доступ к экстранет-группе;

“admin” - роль для сотрудника волонтёрской службы и специалистов технической поддержки;

“worker” - роль для сотрудников музея, не являющихся администраторами.

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

“volunteering” - тип заявки, которая маршрутизируется в модуль по работе с волонтёрами

“name” - ФИО заявителя, проверка на вхождение в «чёрный список»;

“email” - адрес электронной почты, проверка на вхождение в «чёрный список»;

“birth_date” - дата рождения заявителя, проходит проверку по базовым условиям;

“upload_date” - дата подачи заявки, поверка на доступность подачи заявки.

Служебные названия бизнес-процессов и скриптов:

“get_requests” - бизнес-процесс получения и автоматической проверки заявок;

"date_check" - автоматический скрипт проверки даты подачи заявки, запускается внутри бизнес-процесса “get_requests”;

“mailer” - сервис автоматической рассылки писем о статусах заявки.

Статусная модель изменения состояния заявки:

“request” - данные из CRM-формы, отправленные в систему при заполнении формы;

“lead” - сохранённые в системе данные из заявки в формате лида, проходящего автоматические и ручные проверки;

“deal” - сделка - конвертированный лид после принятия сотрудником положительного решения по заявке;

“contact” - контакт - добавленный контакт, имеющий доступ к экстранету и рабочим группам.

Служебные статусы лидов:

“created” - лид создан в CRM и ожидает запуска автоматических проверок;

“reserve” - лид зарегистрирован после установленного срока подачи заявок, не назначается на сотрудников, хранится в резерве, доступен для просмотра и ручной обработки;

“assigned” - лид проходит по базовым условиям и назначен на сотрудника;

“closed” - лид не прошёл проверку на вхождение в чёрный список;

“declined” - лид отклонен сотрудником, данные сохранены в списке «некачественных лидов»;

“accepted” - лид принят сотрудником;

“to_contact” - лид конвертируется в контакт.

Справочник рассылаемых писем:

accept_m - высылается при вынесении положительного решения по заявке, содержит информацию о дате и месте проведения очной встречи для прохождения тренинга по технике безопасности и подписания договора;

decline_m - высылается при вынесении отказа по заявке, содержит список возможных причин отказа (возраст меньше 18 лет, город нахождения, дополнительные комментарии, если сотрудник оставил их в карточке лида при вынесении решения);

blacklist_m - высылается при вхождении контакта в чёрный список, содержит информацию о возможных причинах («Ранее было принято решение о прекращении сотрудничества с Вами»);

reserve_m - высылается при подачи заявки вне сроков приёма новых волонтёров, содержит информацию о добавлении в резервный список;

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

3.2 Целевые бизнес-процессы по работе с волонтёрами ГМИИ им. А. С. Пушкина с использованием CRM

Целевое решение должно соответствовать бизнес-требованиям и быть реализовано в рамках выбранного решения и его доступного функционала. В этом разделе в нотации BPMN описаны целевые процессы по обработке заявки на волонтёрство, взаимодействию в рамках рабочих групп экстранета, а также на «верхнем уровне» детализации описаны типовые сценарии обработки событий в рамках этих процессов.

3.2.1 Бизнес-процесс «подача заявки и регистрация волонтёра»

Графическое описание процесса в нотации BPMN находится в приложениях к работе (см. приложение 6).

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

Кандидат в волонтёры заполняет обязательные поля в анкете, указывает ФИО, контактный телефон, адрес электронной почты. После отправки система оповещает об успешной подачи заявки.

На стороне системы заявка регистрируется в CRM и конвертируется в ЛИД. Запускается автоматическая проверка на вхождение пользователя в «чёрный список»:если контакт, указанный в анкете (ФИО + эл. почта) находится в списке заблокированных, то ЛИД автоматически закрывается, заявка не попадает на ручной отбор сотрудникам волонтёрской службы. По этой заявке автоматически отправляется письмо с отказом.

Лид с «хорошей» заявкой автоматически назначается на сотрудника волонтёрской службы. Если заявка проходит по базовым условия, сотрудник конвертирует лид в сделку. По такой заявке автоматически отправляется письмо с приглашением на очную встречу.

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

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

Если кандидат в волонтёры не пришёл на очную встречу или сотрудник имеет другие причины для отказа, в карточке сделки отмечается неявка. Такая сделка будет закрыта, добавлена в список некачественных контактов, после чего система отправит кандидату письмо с отказом в сотрудничестве.

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

3.2.2 Бизнес-процесс «Запись на задачи и работа в экстранете»

Графическое описание процесса в нотации BPMN находится в приложениях к работе (см. приложение 7).

Процесс начинается после добавления новых волонтёров в экстранет-группу. Сотрудник использует групповой календарь для внесения новых задач и приглашает на неё либо всю группу волонтёров, либо определённые категории.

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

Если задача отмечена сотрудником как важная, система дополнительно отправит письмо с приглашением на неё.

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

3.2.3 Сценарий «подача заявки и регистрация волонтёра»

В таблице ниже на «верхнем уровне» описаны все пользовательские и системные сценарии, необходимые для обработки поступившей заявки на волонтёрство.

Часть действий выполняют пользователи: администратор осуществляет запуск новой CRM-формы, рассматривает поступившие лиды, выставляет по ним решения, отмечает посещение тренинга волонтёром. Кандидат в волонтёры заполняет и отправляет заявку, получает email-рассылку со статусом рассмотрения заявки. Остальные действия осуществляют системные скрипты Bitrix, которые не рассмотрены в этом сценарии, так как являются более техническими деталями процесса и относятся к зоне ответственности разработчиков софта на BitrixFramework; более подробное описание методов может быть найдено в документации для разработчиков Битрикс. В сценариях указаны пользовательские сущности - бизнес-процесс, автоматически обрабатывающий заявки в CRM, а также указан дополнительный метод, проверяющий дату подачи заявки. Также указан универсальный сервис рассылки почтовой нотификации, который настраивается бизнес-процессом и работает со справочниками шаблонов рассылки.

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

Таблица 7 - Сценарий обработки заявки