Основные компоненты разрабатываемого CRM модуля

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

• 1. Пользователь — студент или сотрудник НИУ ВШЭ — Пермь, направляющий заявку со своей проблемой системе.
• 2. Дежурный инженер — работник сервиса технической поддержки НИУ ВШЭ — Пермь, отвечающий за работу с клиентом. Его основной задачей в рамках рассматриваемого модуля является выявление дублирующих заявок и составление списка многоразовых заявок.

Эти агенты будут взаимодействовать с различными модулями системы в той или иной степени.

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

Заявка может находиться в следующих состояниях:

• · Активная — по данной заявке выполняется работа.
• · Дублирующая — такая заявка уже есть в «активных», обработка по ней не ведется, но решение предоставляется её инициатору после того, как оно будет готово для другой такой же заявки.
• · Отмененная — пользователь сам решил проблему и отменил свою заявку, в данном случае она помещается в архив с пометкой «Отменено» для учета статистики.
• · Завершенная — работа по заявке завершена, решение по проблеме предоставлено пользователю, сама заявка помещается в архив портала.

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

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

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

Она связана с CRM модулем через общую папку в сети Интернет, представляющую собой библиотеку документов Sharepoint, куда из CRM модуля после добавления пользователем одноразовой заявки поступает текстовый файл с описанием проблемы пользователя, по которой в базе данных производится поиск возможного решения. Результаты поиска после этого отправляются в виде текстового файла в общую папку. При разработке нового решения WfMS модулем, данное решение вместе с соответствующей технической проблемой также заносятся в базу данных через интерфейс общей папки.

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

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

• · «0 | Идентификатор заявки | Описание технической проблемы» .
• · «1 | Описание технической проблемы пользователя | Решение технической проблемы пользователя | 0 или 1» .

Первая цифра определяет операцию, которую база данных должна будет выполнить. То есть, «0» подразумевает операцию поиска возможного решения по проблеме, а «1» — добавление новой записи в базу данных. При этом, в первом случае файл будет называться «Search» + «Идентификатор заявки», а во втором — «AddToDB» + «Идентификатор заявки». Во втором случае последним элементом строки файла может быть либо «0» либо «1», «0» означает, что для данного решения требуется участие дежурного инженера, а «1» — что оно не требуется.

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

• · «Идентификатор заявки | 1» .
• · «Идентификатор заявки | 0 | 0 или 1 | Решение технической проблемы пользователя» .

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

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

Рисунок 2.3. Структура данных системы Так, основным списком CRM модуля, в рамках которого происходит обработка пользовательских данных, является список заявок. Списки задач, ресурсов и назначений являются списками WfMS модуля, который не рассматривается в рамках данной работы и отвечает за разработку решений технических проблем пользователя.

На рисунке ниже представлена укрупненная структура данных CRM модуля:

Рисунок 2.4. Укрупненная структура данных CRM модуля Общий список модулей обеспечивает взаимодействие двух модулей системы технической поддержки. Так, модуль CRM помещает в него информацию о проблеме пользователя, а модуль WfMS отправляет в него решение заданной технической проблемы.

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

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

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

Рисунок 2.5. Схема разрабатываемого портала Так, из схемы видно, что конкретно к CRM модулю приема и обработки заявок относится список заявок и библиотека документов, представляющая собой общую папку в сети Интернет. При этом общий список модулей доступен обоим модулям системы и обеспечивает их взаимодействие. Внешняя база данных не входит напрямую в интерфейс портала, при этом она является внешним компонентом CRM модуля приема и обработки заявок. При этом программное расширение Sharepoint, обеспечивающее взаимодействие с базой данных, является обработчиком событий, созданным в среде Visual Studio на языке C#. Подробно разработанные компоненты системы рассмотрены в разделе 2.4 «Описание решения» .

Рассмотренная информация по компонентам системы и типам заявок представлена на диаграмме прецедентов на рисунке ниже:

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