· "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. В любой момент времени пользователь должен иметь возможность остановить работу по своей заявке по нажатии на соответствующую кнопку. При этом работа системы по ней прекращается, а сама заявка помещается в список архива с пометкой "Отменено пользователем".

2.4 Описание созданного решения

На основе построенных бизнес-процессов и структуры данных был создан портал в среде MS Sharepoint 2010, включающий в себя два списка и их представления, библиотеку документов, набор рабочих процессов Sharepoint, а также обработчики событий, веб-часть и таймер, созданные в среде Visual Studio на языке C#. Исходный код данных программных доработок можно посмотреть в Приложении В.

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

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

Таким образом, в списке заявок хранится вся информация о текущих и завершенных заявках пользователей. К полям списка относятся:

· id - поле, недоступное для пользователей, содержит идентификатор заявки.

· Наименование проблемы - внутреннее имя "Title", краткое наименование технической проблемы пользователя.

· Описание решений - внутреннее имя "ProblemDescription", описание технической проблемы пользователя.

· Решение - внутреннее имя "Solution", описание решения по технической проблеме пользователя.

· Тип заявки - внутреннее имя "RequestType", тип заявки пользователя - многоразовая, одноразовая или периодическая.

· Период выполнения заявки - внутреннее имя "Period", период, с которым периодическая заявка должна выполняться для пользователя.

· PeriodDate - поле, недоступное для пользователей, содержит дату начала работ по периодическим заявкам.

· Статус заявки - внутреннее имя "RequestStatus", общий статус заявки - актуальная, завершенная или отмененная.

· Текущий статус - внутреннее имя "CurrentStatus", текущее статус работы по заявке.

· Подписка на заявку - внутреннее имя "RequestFrom", имя пользователя, для которого заявка выполняется.

· RequestFromConstant - поле, недоступное для пользователей, содержит имя пользователя, для которого должна выполняться многоразовая заявка, необходимо для корректной обработки многоразовых заявок.

· На главную страницу - внутреннее имя "AddAtHome", поле условного типа, показывает нужно ли отображать заявку пользователя на главной странице или нет.

· Обратная связь - внутреннее имя "Feedback", комментарий пользователя о работе системы по его заявке.

· Статус решения - внутреннее имя "SolvedUserReaction", показывает статус текущего решения по заявке: в разработке, помогло пользователю или не помогло пользователю.

· Отменить заявку - внутреннее имя "Cancel", поле условного типа, показывает нужно ли отменить выбранную заявку или нет.

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

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

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

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

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

Для данного списка созданы настраиваемые формы добавления, редактирования и просмотра, в которых, в зависимости от типа текущего пользователя, ряд полей недоступны либо доступны только для просмотра. Так, все дежурные инженеры компьютерного центра на портале должны быть добавлены в группу "Help Desk", а студенты и сотрудники ВУЗа - в группу "Common Users".

Также для данного списка были созданы следующие представления:

· Заявки текущего пользователя - все заявки, поле "Подписка" которых соответствуют имени текущего пользователя портала.

· Многоразовые заявки - все заявки, поле "Тип" которых принимает значение "Многоразовые", и поле "Подписка" не содержит данных.

· Актуальные заявки - все заявки, находящиеся в статусе "Актуальная", и для которых поле "На главную страницу" принимает значение "true".

· Завершенные заявки - все заявки, для которых поле "ProblemSolved" принимает значение "true".

В общем списке модулей хранится информация о заявках, которые находятся в обработке WfMS модуля. К полям списка относятся:

· Идентификатор заявки - внутреннее имя "request_id", идентификатор заявки из списка заявок.

· Заявка - внутреннее имя "Request", поле подстановки, по нажатии на которое откроется соответствующая заявка.

· Описание проблемы - внутреннее имя "ProblemDescription", описание технической проблемы пользователя.

· Решение - внутреннее имя "Solution", описание решения по технической проблеме пользователя.

· Решение подготовлено - внутреннее имя "SolutionPrepared", поле условного типа, показывает завершена ли работа WfMS модуля по данной заявке.

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

Для данного списка никаких представлений не предусмотрено.

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



Рисунок 2.6. Общая структура и взаимосвязь подсистем Сервиса

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

2. Подсистема обработки заявок представляет собой набор рабочих процессов Sharepoint, а также обработчиков событий и таймера, созданных в среде Visual Studio на языке C#. В совокупности они позволяют организовать процесс обработки заявок различных типов.

3. Подсистема хранения заявок представляет собой набор настраиваемых списков SharePoint и их представлений, необходимых для хранения и предоставления информации обо всех заявках пользователей.

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

5. Подсистема перенаправления пользователей представляет собой набор пользовательских форм и настраиваемую веб-часть, созданную в среде Visual Studio на языке C#. Данная веб-часть находится на стандартных формах создания и редактирования элементов. Она осуществляет проверку, является ли текущий пользователь дежурным инженером, и, в зависимости от результата, перенаправляет его на соответствующую форму.

6. Интерфейс взаимодействия модуля CRM с базой данных представляет собой библиотеку документов, представляющую собой общую папку, и набор обработчиков событий, созданных в среде Visual Studio на языке C#. Данный интерфейс позволяет автоматически создавать файлы с описанием технической проблемы или полной информацией по заявке и отправлять их в общую папку, также интерфейс подразумевает обработку поступающих из базы данных в общую папку файлов. Формат файлов описан в техническом задании к разрабатываемому модулю в Приложении Б.

7. Интерфейс взаимодействия модуля CRM с модулем WfMS представляет собой общий список данных модулей, включащий набор рабочих процессов Sharepoint и обработчиков событий, созданных в среде Visual Studio на языке C#, которые в совокупности позволяют на разных этапах обработки заявки, в зависимости от её текущего состояния, создавать элемент в данном списке, что само по себе является триггером для начала работы WfMS модуля.

Подсистемы модуля состоят из набора компонент, взаимодействующих между собой. Схема взаимодействия компонентов данных подсистем представлена на рисунке ниже:



Рисунок 2.7. Схема взаимодействия компонентов подсистем модуля

В таблице ниже представлено описание разработанных компонентов подсистем модуля:

Таблица 2.1. Описание компонентов подсистем модуля

Компоненты системы	Описание
Подсистема добавления заявок
Рабочий процесс "Добавление элемента в список заявок"	При добавлении заявки устанавливаются значения полей идентификатора заявки, её статуса и статуса решения, подписки на заявку, а также всех полей условного типа. Помимо этого для всех заявок обнуляются поля решения и обратной связи, для многоразовых и одноразовых заявок обнуляется значение поля периода, а для одноразовых заявок значение поля "sendToExchange" изменяется на "true", таким образом для данного типа заявок осуществляется поиск решения во внешней базе данных.
Подсистема обработки заявок
Рабочий процесс "Изменение элемента в списке заявок"	Рабочий процесс запускается при изменении элемента в списке. В том случае, если пользователь ставит маркер в поле "Отменить заявку", то одноразовые заявки помещаются в архив с пометкой "Отменено пользователем", а периодические помечаются как завершенные, и работы по ним впоследствии не выполняются. Также в случае, когда заявка помечается дежурным инженером как дублирующая, то он должен занести в поле "Решение" ссылку на идентичную заявку, после чего пользователю автоматически будет отправлено уведомление со ссылкой на данную заявку.
Рабочий процесс "Проблема решена или нет"	Рабочий процесс запускается после того, как решение было отправлено пользователю и он указал помогло ли оно ему или нет. Если решение не помогло пользователю, то поле "sendToWfms" принимает значение "true" и заявка перенаправляется в WfMS модуль. Если решение помогло пользователю, то заявка помечается как завершенная, для одноразовых заявок поле "sendToExchange" принимает значение "true" и заявка отправляется в общую папку с базой данных.
Обработчик события "ItemAddedReceiver"	Программный код, разработанный на языке C#. С помощью данного программного расширения после добавления периодической заявки на портал осуществляется её перенаправление в WfMS модуль изменением поля "sendToWfms". Помимо этого, в зависимости от периодичности заявки, в поле "PeriodDate" заносится следующая дата, когда данная заявка должна будет выполняться.
Обработчик события "ItemUpdatedReceiver"	Программный код, разработанный на языке C#. С помощью данного программного расширения при добавлении пользователем своего имени в поле "Подписка" многоразовой заявки создается новая заявка, при этом, если решение данной заявки требует участия дежурного инженера, то поле "sendToWfms" принимает значение "true" и заявка перенаправляется в WfMS модуль. Если решение не требует участия дежурного инженера, то поле "SendNotificationToUser" принимает значение "true" и пользователю высылается уведомление о решении. При этом поле "Подписка" у основной многоразовой заявки обнуляется.
Таймер "ListTimerJob"	Таймер, разработанный на языке C#. Данное программное расширение позволяет ежедневно проверять, если ли в списке заявок такие периодические заявки, которые должны быть выполнены в день запуска таймера. Если такие заявки есть, и их решение требует участия дежурного инженера, то поле "sendToWfms" принимает значение "true" и заявка перенаправляется в WfMS модуль. Если решение не требует участия дежурного инженера, то поле "SendNotificationToUser" принимает значение "true" и пользователю высылается уведомление о решении. После этого, в зависимости от периодичности заявки, в поле "PeriodDate" заносится следующая дата, когда данная заявка должна будет выполняться.
Подсистема хранения заявок
Список заявок	Представляет собой список, где хранятся все текущие и завершенные заявки пользователей. Включает в себя следующие представления: заявки текущего пользователя, актуальные заявки, многоразовые заявки, завершенные заявки.
Подсистема отправки уведомлений пользователям
Рабочий процесс "Изменение элемента в списке заявок"	Рабочий процесс запускается, когда поле "SendNotificationToUser" списка заявок принимает значение "true". В данном случае пользователю на портале и по электронной почте высылается форма, где указано подготовленное решение по его техничяеской проблеме. Также по нажатию на соответствующую кнопку на данной форме пользователь указывает, помогло ли ему данное решение или нет. Помимо этого, пользователь может добавить на форме свой комментарий о работе системы.
Подсистема перенаправления пользователей
Веб часть "UserRedirect"	Веб-часть начинает работу, когда пользователь пытается зайти на форму создания или редактирования элемента. Осуществляется проверка, принадлежит ли текущий пользователь к группе дежурных инженеров, и если да, то происходит перенаправление пользователя на соответствующую форму, где доступны дополнительные поля.
Набор пользовательских форм	Для дежрных инженеров компьютерного центра и обычных пользователей системы (студенты и сотрудники НИУ ВШЭ - Пермь) предусмотрены различные формы создания и редактирования заявок. Так, обычные пользователи не имеют возможности создать многоразовые заявки, изменять поле "Решение" или отметить заявку как дублирующую. При этом дежурные инженеры имеют полный доступ к основным полям всех заявок.
Интерфейс взаимодействия модуля CRM с базой данных
Библиотека документов "Exchange"	Библиотека документов представляет собой общую с базой данной папку, содержащую два каталога: "Export" и "Import". В папку "Export" помещаются файлы из модуля CRM, они могут содержать либо описание проблемы, для которой необходимо найти решение, либо полную информацию о заявке для занесения её в базу данных. В папку "Import" помещаются файлы из базы данных, которые содержат либо найденное решение по заданной проблеме либо маркер того, что по заданной проблеме ничего не было найдено. Формат файлов описан в техническом задании к разрабатываемому модулю в Приложении Б.
Обработчик события "ItemUpdatedReceiver"	Программный код, разработанный на языке C#. С помощью данного программного расширения при изменении значения поля "sendtoExchange" на "true", создается файл с описанием технической проблемы и отправляется в папку "Export" библиотеки "Exchange". Если заявка при этом является завершенной, то есть поле "ProblemSolved" = "true", то в данную папку отправляется файл с полной информацией о заявке для её занесения в базу данных.
Обработчик события "AddedImportFile"	Программный код, разработанный на языке C#. С помощью данного программного расширения при добавлении файла в папку "Import" библиотеки "Exchange" происходит чтение информации из данного файла, после чего, если решение найдено, то поле "SendNotificationToUser" принимает значение "true" и пользователю высылается уведомление о решении. Если решение не было найдено, то поле "sendToWfms" принимает значение "true" и заявка перенаправляется в WfMS модуль.
Интерфейс взаимодействия модуля CRM с модулем WfMS
Общий список модулей	Представляет собой список, куда модуль CRM перенаправляет заявки, требующие разработки нового решения либо выделения дежурного инженера на задачу. WfMS модуль, в свою очередь, помещает в соответствующие поле элемента списка решение заданной технической проблемы.
Рабочий процесс "Изменение элемента в списке заявок"	Рабочий процесс запускается, когда поле "sendToWfms" списка заявок принимает значение "true". В данном случае создается новый элемент в общем списке модулей системы, куда помещается описание технической проблемы и идентификатор заявки. В том случае, если необходимо выделить дежурного инженера на задачу, то также заполняются поля "Решение" и "Требует инженер".
Рабочий процесс "Изменение элемента в общем списке"	Рабочий процесс запускается, когда поле "Решение подготовлено" общего списка модулей системы принимает значение "true". В данном случае по идентификатору заявки находится нужный элемент в списке заявок, в поле "Решение" которого заносится соответствующая информация. Если данное решение требует участия дежурного инженера, то в поле "NeedWorker" списка заявок заносится значение "true". После этого поле "SendNotificationToUser" данного заявок принимает значение "true" и пользователю высылается уведомление о решении.

Далее рассмотрен процесс работы пользователей на портале.

В первую очередь необходимо отметить, что на портале были созданы две группы пользователей: обычные пользователи системы (студенты и сотрудники НИУ ВШЭ - Пермь) и дежурные инженеры компьютерного центра. Так, все дежурные инженеры компьютерного центра на портале должны быть добавлены в группу "Help Desk", а студенты и сотрудники ВУЗа - в группу "Common Users". Для каждой из этих групп существуют свои ограничения при работе с заявками, поэтому для них были созданы разные формы редактирования и добавления заявок. Так, обычные пользователи не могут напрямую указывать тип заявки, это сделано для того, чтобы исключить возможность создания ими многоразовых заявок. Таким образом, каждая создаваемая ими заявка изначально будет считаться одноразовой, но если при этом пользователь укажет период выполнения работ по ней, то она уже будет являться периодической. Помимо этого, дежурным инженерам, в отличие от обычных пользователей, доступны поля решения технической проблемы и статуса, где они могут указать, что выбранная заявка является дублирующей, но при этом они не могут редактировать поля периода выполнения заявки и обратной связи.

На рисунке ниже представлены формы добавления заявки для обоих видов пользователей системы, для дежурных инженеров - слева, для обычных пользователей - справа:



(а) (б)

Рисунок 2.8. Формы добавления заявок для разных типов пользователей: (а) - для дежурных инженеров, (б) - для обычных пользователей.

На рисунке ниже представлены формы редактирования заявки для обоих видов пользователей системы, для дежурных инженеров - слева, для обычных пользователей - справа:

(а) (б)

Рисунок 2.9. Формы редактирования заявок для разных типов пользователей: (а) - для дежурных инженеров, (б) - для обычных пользователей.

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

Далее рассмотрен процесс работы студентов и сотрудников НИУ ВШЭ - Пермь на портале с учетом различных типов заявок.

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

Рисунок 2.10. Главная страница портала

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



Рисунок 2.11. Форма редактирования, подписка на многоразовую заявку

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

Рисунок 2.12. Общий список модулей

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

Рисунок 2.13. Форма уведомления о решении

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

У пользователя есть возможность перейти к представлению "Мои заявки" в меню слева, в данном представлении он может посмотреть список всех своих заявок, а также добавить новые. Скриншот представления можно увидеть ниже:

Рисунок 2.14. Представление "Мои заявки"

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

Рисунок 2.15. Создание новой одноразовой заявки

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

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

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

При добавлении заявки пользователь может обозначить её как периодическую, при этом выбрав период её выполнения (рис 2.16):

Рисунок 2.16. Добавление периодической заявки

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

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

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

Все заявки после осуществления работ по ним помещаются в архив портала. Ниже представлен скриншот архива портала:

Рисунок 2.17. Архив портала

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



Рисунок 2.18. Восстановление старой заявки

2.5 Экономическое описание решения

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

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

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

Разработка системы велась бесплатно в рамках выпускной квалификационной работы. Для её создания использовалось программное обеспечение, входящее в академическую подписку факультета бизнес-информатики на продукты компании Microsoft. Стоимость данной подписки составляет 35 тысяч рублей в год. Используемое по ней программное обеспечение включает:

· Microsoft Sharepoint 2010;

· Microsoft Visual Studio 2010;

· Microsoft SQL Server 2008;

· Microsoft Windows Server 2008 R2.

Помимо этого, для создания системы использовался Sharepoint Designer 2010, который распространяется компанией Microsoft бесплатно.

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

Помимо этого, после внедрения системы необходимо будет регулярно выделять дежурного инженера компьютерного центра ВУЗа для осуществления её поддержки и сопровождения.

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

· Проверка и исправление контента портала. Трудозатраты составляют 1 чел./ч. в день.

· Проверка актуальных заявок на наличие дублирующих. Трудозатраты составляют 0.5 чел./ч. в день.

· Анализ архива портала, выявление наиболее часто встречающихся проблем пользователей и создание многоразовых заявок по ним. Трудозатраты составляют 1 чел./ч. в день.

Так, трудозатраты по сопровождению системы составляют 2.5 чел./ч. в день. Исходя из расчета, что количество рабочих дней в месяц в среднем составляет 22 дня, то предполагаемые временные затраты на сопровождение системы составляют около 55 чел./ч. (22*2,5=55) в месяц. Таким образом, стоимость сопровождения системы должна будет высчитываться на основе месячной зарплаты выделяемого на задачу работника компьютерного центра.

Заключение

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

Помимо этого была рассмотрена текущая модель оказания технического обслуживания студентам и сотрудникам НИУ ВШЭ - Пермь, были выявлены её недостатки. После чего в нотации ARIS была построена модель бизнес-процессов, протекающих внутри разрабатываемого модуля.

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

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

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

Спроектированный портал был создан в среде MS Sharepoint 2010. На данный портал были добавлены соответствующие списки и их представления. При помощи рабочих процессов Sharepoint, а также обработчиков событий и таймера, созданных в среде Visual Studio на языке C#, был организован процесс приема и обработки заявок пользователей системы. При помощи набора созданных форм для разных типов пользователей, стандартных веб-частей Sharepoint и настраиваемой веб-части, разработанной в среде Visual Studio на языке C#, был реализован пользовательский интерфейс портала.

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

Помимо этого, приведено экономическое описание данного решения, где рассчитана стоимость внедрения системы и её дальнейшего сопровождения.

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

Библиографический список

1. Семушин Д.В. Выпускная квалификационная работа бакалавра на тему "Управление потоками работ вычислительного центра ВУЗа". Пермь, НИУ ВШЭ - Пермь, 2014 г.

2. Yu E. "Information Systems (in the Internet Age)" Practical Handbook of Internet Computing, M.P. Singh (ed.) CRC Press 2004. pp. 33: 1 - 19.

3. Ефремов О.В., Беляев П.С. "Информационные системы в науке, образовании и бизнесе". Тамбов: Издательство тамбовского государственного университета, 2006 г.

4. Информационные процессы, информационные системы // Неофициальный сайт Барановичского Государственного Университета [Электронный ресурс] [Режим доступа: http://bargu.by/2511-informacionnye-processy-informacionnye-sistemy.html] [Проверено: 01.06.2014].

5. "What is an information system?" Management Information Systems (MIS) 2011/2012. Lecture 3.

6. Тельнов Ю.Ф. "Интеллектуальные информационные системы (Учебное пособие)". Московский международный институт эконометрики, информатики, финансов и права, 2002 г.

7. Pienaar H. "Design and development of an academic portal". Academic Information Service, University of Pretoria, South Africa. Libri, 2003, vol. 53, pp. 118-129.

8. Интернет-портал // Уникальный портал its-my-site.ru [Электронный ресурс] [Режим доступа: http://its-my-site.ru/ripavleoklivl18/Интернет-портал] [Проверено: 01.06.2014].

9. "Critical steps to successful CRM". Staffware eCRM, 2000.

10. "Introduction to CRM". [Электронный ресурс] [Режим доступа: http://dl.sugarforge.org/training/training/IntroductiontoCRM/CRM_Fundamentals.pdf] [Проверено: 01.06.2014].

11. "Introduction to Customer Relationship Management". Chapter 1. // Francis Buttle & associates: experts in customer management [Электронный ресурс] [Режим доступа: http://buttleassociates.com/doc/Chapter1CRMbook2e.pdf] [Проверено: 01.06.2014].

12. Sharma P. Building a winning Service Desk, QAI India Ltd, 2010.

13. Rizzo T., Fried J., Hillier S., Schaefer K., Swider P., Alirezaei R. Professinal Sharepoint 2010 Development, 2nd ed. Indianapolis: John Wiley & Sons, Inc., 2012.

Приложение А. Описание бизнес-процессов CRM модуля приема и обработки заявок

Рисунок А.1. Основной бизнес-процесс



Рисунок А.2. Прием заявки



Рисунок А.3. Подготовка решения по заявке

Рисунок А.4. Предоставление решения пользователю



Рисунок А.5. Завершение работы по заявке



Рисунок А.6. Вспомогательный процесс добавления многоразовых заявок

Приложение Б. Техническое задание

Настоящее техническое задание определяет форму и содержание работ по разработке модуля системы технической поддержки НИУ ВШЭ - Пермь, отвечающего за взаимодействие работников компьютерного центра со студентами и сотрудниками университета. Данный модуль является частью системы технической поддержки университета, которая также включает модуль разработки решений по техническим проблемам пользователей, описание которого представлено в работе "Управление потоками работ вычислительного центра ВУЗа".

1. Общие сведения

1.1 Полное наименование модуля и его условное обозначение

Наименование модуля системы - "CRM модуль приема и обработки заявок с техническими проблемами студентов и сотрудников НИУ ВШЭ - Пермь".

1.2 Шифр темы

Настоящее Техническое задание разработано в рамках выполнения выпускной квалификационной работы студентов факультета бизнес-информатики, направления 080500.62 Бизнес-информатика.

1.3 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы

Работа выполняется на основании учебного плана и темы выпускной квалификационной работы, определенной научным руководителем и утвержденной приказом от 25.11.2013 №8.2.6.2-06/698 "Об утверждении тем и руководителей выпускных квалификационных работ студентов факультета бизнес-информатики".

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

Плановые сроки начала работ по проектированию разработке системы установлены на сентябрь 2013 года. Сдача проекта должна быть осуществлена до 20 мая 2014 года.

2. Назначение и цели создания модуля

2.1 Назначение модуля

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

2.2 Цель создания модуля

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

3. Характеристика объектов автоматизации

В рамках данного модуля автоматизируются процессы получения и обработки заявок с техническими проблемами студентов и сотрудников НИУ ВШЭ - Пермь.

4. Требования к модулю

4.1 Общие требования к модулю

4.1.1 Требования к структуре и функционированию модуля

Модуль должен включать следующие подсистемы:

1. Подсистема приема и обработки заявок пользователя.

2. Подсистема поиска возможных решений технических проблем в базе данных.

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

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

4.1.2 Требования к численности и квалификации персонала системы

Для эксплуатации и поддержания модуля системы определены следующие роли:

1. Системный администратор.

2. Дежурный инженер.

3. Пользователи системы (студенты, сотрудники кафедр).

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

4.1.3 Требования к численным показателям модуля

Время хранения данных определяется внутренними нормативными документами. Доступ к модулю системы должен быть предоставлен всем студентам Пермского кампуса НИУ ВШЭ.

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

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

4.1.4 Требования к временным показателям модуля

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

· Добавление заявки на портал - не более 1 минуты 30 секунд. Включает загрузку введенной пользователем информации в элемент списка портала.

· Обработка заявки - не более 2 минут. Включает отправку файла в общую папку для поиска решения по заданной проблеме во внешней базе данных.

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

· Просмотр заявки - не более 1 минуты. Включает загрузку информации по выбранной заявке на форму.

· Оформление отчета о работе - не более 2 минут. Включает сбор основной информации по заявке, формирование по ней файла MS Word и его сохранение в соответствующей папке библиотеки.

4.1.5 Требования к надежности

· Модуль должен функционировать 24 часа в день, 7 дней в неделю.

· Заявка пользователя должна добавляться на портал и обрабатываться без ошибок и преждевременных завершений.

· В случае, если решение текущей проблемы по заявке есть в базе знаний портала, система должна находить его в 80% случаев.

· Отчет должен оформляться по каждой заявке после завершения работы системы с ней.

4.1.6 Требования к защите информации от несанкционированного доступа

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

Для обеспечения защиты данных пользователя должна быть предусмотрена аутентификация пользователей на основе средств Active Directory операционной системы.

Должны быть предусмотрены механизмы защиты сведений персонального характера пользователей от несанкционированного доступа к ним других пользователей системы.

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

4.2 Требования к функциям, выполняемым модулем

На создаваемом портале CRM модуля приема и обработки заявок должны быть реализованы следующие функции:

1. Аутентификация должна производиться средствами Active Directory операционной системы.

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

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

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

5. На главной странице портала пользователю должен быть доступен список многоразовых заявок, где пользователь может подписаться на выполнение для него выбранной заявки. Готовое решение должно быть выслано пользователю, при необходимости на работу по заявке должен быть выделен дежурный инженер.

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

7. В случае, если ранее решенная техническая проблема пользователя вновь появилась у него, он должен иметь возможность поставить нужную завершенную заявку на выполнение в представлении "Заявки текущего пользователя". В данном случае заявка должна быть перенаправлена в WfMS модуль для разработки нового решения.

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

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

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

11. На форме с высылаемым пользователю решением должны быть реализованы кнопки "Решение помогло" и "Решение не помогло", при нажатии на первую кнопку работа по заявке завершается, при нажатии на вторую - заявка вновь пересылается в WfMS модуль для разработки нового решения. Помимо этого, форма должна содержать поле, куда пользователь при желании может написать свое впечатление о работе с системой.

12. Для одноразовых заявок, решение по которым было получено из WfMS модуля, разработанное решение вместе с описанием проблемы пересылается в общую папку, к которой имеет доступ база данных, куда данное решение впоследствии заносится.

13. В любой момент времени пользователь должен иметь возможность остановить работу по своей заявке по нажатии на соответствующую кнопку. При этом работа системы по ней прекращается, а сама заявка помещается в список архива с пометкой "Отменено пользователем".

4.3 Требования к программной и информационной совместимости

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

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

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

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

...