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

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

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

Система представляет собой веб-портал, созданный в среде MS Sharepoint 2010. Модуль предназначен для автоматизации получения и обработки заявок пользователей с их техническими проблемами. Пользователями данной системы являются студенты и сотрудники НИУ ВШЭ — Пермь.

Для осуществления взаимодействия CRM и WfMS модулей системы технической поддержки НИУ ВШЭ — Пермь, необходимо, чтобы они были реализованы в пределах одной фермы MS Sharepoint 2010 с использованием программных доработок на языках С# и Javascript.

Взаимодействие CRM и WfMS модулей осуществляется через общий список, куда первый модуль заносит данные о проблеме, а второй — о конечном решении технической проблемы.

Одним из компонентов модуля 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» — что оно не требуется.

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

• 1. Аутентификация должна производиться средствами Active Directory операционной системы.
• 2. На портале должен быть создан список заявок со следующим набором представлений: актуальные заявки, многоразовые заявки, заявки текущего пользователя, завершенные заявки.
• 3. На главной странице портала пользователь должен иметь возможность посмотреть список актуальных на данный момент заявок, а также информацию по каждой проблеме в выбранной им заявке.
• 4. На портале должны быть предусмотрены механизмы обработки различных типов заявок: одноразовых (вводятся пользователем единовременно и выполняются для него один раз), периодические (подразумевают выполнение определенной задачи для пользователя с заданной периодичностью), многоразовые (создаются дежурными инженерами, несколько пользователей могут подписаться на выполнение таких заявок для себя).
• 5. На главной странице портала пользователю должен быть доступен список многоразовых заявок, где пользователь может подписаться на выполнение для него выбранной заявки. Готовое решение должно быть выслано пользователю, при необходимости на работу по заявке должен быть выделен дежурный инженер.
• 6. В случае если заявка пользователя является периодической, то она должна выполняться с определенной периодичностью. Готовое решение должно быть выслано пользователю, при необходимости на работу по заявке должен быть выделен дежурный инженер.
• 7. В случае, если ранее решенная техническая проблема пользователя вновь появилась у него, он должен иметь возможность поставить нужную завершенную заявку на выполнение в представлении «Заявки текущего пользователя». В данном случае заявка должна быть перенаправлена в модуль WfMS для разработки нового решения.
• 8. На главной странице портала пользователь должен иметь возможность перейти к представлению «Заявки текущего пользователя» для регистрации своей проблемы, в данном представлении пользователь должен иметь возможность создавать элемент с описанием его текущей проблемы, указывая при этом краткое наименование проблемы, её описание, а также будет ли его заявка отображаться на главной странице портала как актуальная на данный момент. Помимо этого пользователь может поставить для заявки маркер периодической, добавив информацию о том, с какой периодичностью для него необходимо выполнять данную заявку (ежедневная, еженедельная, ежемесячная, ежеквартальная, полугодовая, годичная).
• 9. После добавления одноразовой заявки на портал система должна формировать файл с описанием технической проблемы пользователя и отправлять его в общую папку, которая является интерфейсом взаимодействия с базой данных, где производится поиск решений по заданной проблеме. В обратном направлении из базы данных в общую папку отправляется файл с результатами поиска. Если решение найдено в базе данных, то оно высылается пользователю, при необходимости на работу по заявке должен быть выделен дежурный инженер. Если найденное решение не помогло пользователю решить его техническую проблему либо никаких решений не было найдено, то модуль CRM запускает триггер (изменение поля элемента общего списка систем), по которому начинает свою работу WfMS модуль, ответственный за разработку решения. Описание данной системы представлено в работе «Управление потоками работ вычислительного центра ВУЗа» .
• 10. В результате работы WfMS модуля в общий список модулей системы добавляется решение текущей проблемы пользователя, которое впоследствии высылается пользователю.
• 11. На форме с высылаемым пользователю решением должны быть реализованы кнопки «Решение помогло» и «Решение не помогло», при нажатии на первую кнопку работа по заявке завершается, при нажатии на вторую — заявка вновь пересылается в WfMS модуль для разработки нового решения. Помимо этого, форма должна содержать поле, куда пользователь при желании может написать свое впечатление о работе с системой.
• 12. Для одноразовых заявок, решение по которым было получено из WfMS модуля, разработанное решение вместе с описанием проблемы пересылается в общую папку, к которой имеет доступ база данных, куда данное решение впоследствии заносится.
• 13. В любой момент времени пользователь должен иметь возможность остановить работу по своей заявке по нажатии на соответствующую кнопку. При этом работа системы по ней прекращается, а сама заявка помещается в список архива с пометкой «Отменено пользователем» .