Файл: Автоматизация обработки обращений в службу технической поддержки для ООО «Грин Порт».pdf

Business critical system - системы имеющие высокий статус критичности для реализуемых компанией коммерческих и финансовых операций, для данных систем определен режим работы 24/7/365 и простой более 2-х часов является критичным и ведет к значительным финансовым или репутационным издержкам. Т.к. основным прибылеобразующим направлением для компании является предоставление логистических услуг, то на их примере был выполнен расчет максимально временного показателя по следующей формуле:

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

Business Operational system – системы имеющее важное, но не критичное для бизнеса значение, не требующие работы в реальном времени, но достаточно важные для эффективной и продуктивной работы сотрудников. Для данных систем признано эффективным значение про времени реакции и устранения проблемы по инциденту в течение 5-6 часов.

Office Production – системы не критичные для бизнеса с точки зрения немедленного восстановления доступности, но имеющие важное значение с точки зрения сохранности данных. Принятое допустимым время восстановления 24 часа.

Кроме того, для определения количественных характеристик уровня предоставления услуг и сервисов были рассчитаны следующие требования SLA (Service Level Agreement) с использованием формулы:

Tдост = (Тпред — Тпрост)/ Тпред

где Тпред – согласованное время предоставления услуги, Тпрост – сумма простоев за период.

Так для Business critical system был определены следующие уровни SLA:

В месяц: 99.95% (допустимо около 20 минут недоступности сервиса)

В год: 99.975% (допустимо около 2 часов недоступности сервиса)

Для Business Operational system был определены следующие уровни SLA:

В месяц: 99.45% (допустимо около 4 часов недоступности сервиса)

В год: 99.55% (допустимо около 1 дня недоступности сервиса)

Для Office Production был определены следующие уровни SLA:

В месяц: 99.45% (допустимо около 4 часов недоступности сервиса)

В год: 99.35% (допустимо около 2 дней недоступности сервиса)

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

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

---

2. Состав информационной системы

Архитектуры системы

Система представляет из себя клиент-серверную структуру, построенную на использовании web-технологий. Основное взаимодействие пользователя с системой производится через web-интерфейс, так же возможно размещение заявки посредством звонка на номер поддержки или отправкой сообщен на заранее определенный почтовый адрес (этот функционал будет рассмотрен в следующих модулях). Структурно web-интерфейс состоит из нескольких модулей связанных между собой. Для создания основных программных средств используются язык PHP и язык разметки HTML, так же, для отображения активного содержимого веб-страниц используется Java. Процесс взаимодействия используемых модулей между собой кратко отображен на следующей схеме:

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

Состав системы

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

1. Модуль взаимодействия с пользователем
2. Модуль взаимодействия с оператором технической службы
3. Модуль информирования
4. Модуль администрирования
5. База данных
6. Модуль авторизации (единой точки входа SSO)
7. Модуль интеграции с почтовым сервисом
8. Модуль интеграции с системой телефонии
9. Модуль сбора и отображения статистики

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

Хранение всей информации выполняется в реляционной базе данных (для проектируемой системы предполагается использовать свободно распространяемую версию базы данных MySQL).

Рассмотрим отдельной каждый модуль в отдельности:

Модуль взаимодействия с пользователем.

Служит для взаимодействия пользователя с системой SrviceDesk и оформления заявки. Вход в данный модуль выполняется через адресную строку любого браузера. На данном этапе от пользователя требуются ввод логина и пароля, после чего учетные данные пользователя будут переданы в модуль сквозной авторизации пользователя (SSO), на основе которого пользователь будет идентифицирован с учетными данными в службе каталогов (Active Directory), на основе которых будут заполнены поля ФИО, должности, отдел и место расположения пользователя. От пользователя потребуется заполнить следующие поля:

---

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

Следующие поля в заявке заполняются автоматически:

• Присвоение уникального, в данной системе, ID для заявки.
• ФИО пользователя (будет получено через модуль SSO из службы каталогов Active Directory)
• Должность (будет получено через модуль SSO из службы каталогов Active Directory)
• Отдел (будет получено через модуль SSO из службы каталогов Active Directory)
• Подразделение (будет получено через модуль SSO из службы каталогов Active Directory)
• Номер телефона (будет получено через модуль SSO из службы каталогов Active Directory)

Структурная схема данного модуля (редактируемые и заполняемые автоматически поля) отражена на следующей схеме:

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

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

• Переадресация заявки на конкретного исполнителя
• Назначение заявки себе в работу
• Запрос уточняющих данных у пользователя
• Закрытие заявки с указанием статуса
• Эскалация заявки на 2-й уровень поддержки

Модуль информирования

Данный модуль взаимодействует с почтовой службой предприятия и служит для информирования пользователей и исполнителей об открытии заявки, изменении её статуса, запросе дополнительных сведений по заявке. Взаимодействие с данным модулем происходит на основе уникального номера (ID) присваиваемого заявке в рамках пользовательского обращения. Событие отправки сообщения происходит во всех перечисленных случаях. В качестве поля адресата используется почтовый адрес инициатора заявки, полученный, так же, через службу SSO из службы каталогов AD.

Для исполнителей заявок адреса получателей указываются в зависимости от категории заявки, её срочности и той ИС по которой возник инцидент. Учетные данные исполнителей

База данных

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

---

На основе внутреннего соглашения принята следующая система шифра для ID заявки:

Код ИС – код информационной системы по которой производится обращение. Это позволяет идентифицировать систему, по которой произведено обращение. На основе данного ID производится определение категории заявки. В дальнейшем этот идентификатор служит для определения статистики сбоев и обращений по конкретной ИС.

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

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

Для Business critical system были определены следующие приоритеты

1 – наивысший приоритет (Заявка эскалируется непосредственно на 2-й уровень поддержки и руководству информационного подразделения)

2 – высокий приоритет (Заявка эскалируется на 2-й уровень техподдержки, после выбрано периода времени, определенного для решения инцидента эскалируется на уровень руководства подразделения)

Для Business Operational system были определены следующие приоритеты

3 – Средний приоритет, заявка поступает на 1-й уровень техподдержки, в случае отсутствия решения за отведенное время и ручной эскалации на увровень выше производится автоматическая паредача заявки на 2-й уровень поддверки.

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

Для Office Production были определены следующие приоритеты:

5 – низкий приоритет, заявка поступает на 1-й уровень техподдержки, в случае отсутствия решения за отведенное время и ручной эскалации заявка закрывается, время на решение заявки соответствует нижней границе SLA.

Полная схема базы данных в соответствии с ER моделью отражена в Приложении 1

Ниже рассмотрена одна из таблиц базы данных служащая для хранения заявок (ticket)

Пример фрагмента описания структуры записей таблицы «ticket»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Уникальный номер заявки	ID	строка	5	ключевое поле
Поле описания заявки	tn	строка	300
Идентификатор пользователя	user_id	строка	50
Группа пользователя	group_id_	строка	20
Идентификатор приоритета	ticket_priority_id	строка	50
Поле статуса заявки	ticket_lock_id	строка	20
Поле решения по заявке	ticket_answered	число	8
Идентификатор исполнителя	customer_id	строка	15
Учетная запись исполнителя	customer_user_id	строка	30
Время создания	create_time	строка	8
Адрес пользователя	user_mail	строка	15
Адрес исполнителя	customer_mail	строка	15

---

Модуль авторизации (единой точки входа SSO)

Данный программный модель необходим для предоставления пользователю единой точки входа в систему (SSO - Single sign-on). Данный сервис позволяет связать имеющуюся у пользователя учетную запись пользователя домена Active Directory с учетной записью в системе HelpDesk. Пройдя процедуру аутентификации в одном из сервисов, пользователь автоматически получает доступ ко всем остальным, что избавляет его от многократного ввода данных своей учётной записи. Для сквозной авторизации пользователя используется разработанный компанией Microsoft протокол Kerberos.

Принцип сквозной авторизации состоит в следующем:

После успешной первичной аутентификации центр распределения ключей (Key Distribution Center, KDC) выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к системе учета заявок — Service Ticket (TGS). Кроме того, в авторизации учетной записью Active Directory есть другие преимущества, в частности данный тип авторизации позволяет использовать другие пользовательские поля данных, определенные в Active Directory. В частности, поля Группа, Отдел, Подразделение, Телефон, E-mail и другие. Это освобождает пользователя от необходимости заполнять данные поля при составлении заявки и позволяет получить более прозрачную и информативную систему идентификации пользователя.

Модуль интеграции с почтовым сервисом

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

DTMF (Dual-tone multi-frequency) — тональный сигнал в полосе голосовых частот, с помощью которого обмениваются информацией телефоны (иди другие телефонные устройства) и АТС по аналоговым линиям связи. В частности, DTMF используется для тонального набора телефонного номера, а также в интерактивных телефонных системах. Стандарт, описывающий тональный набор номера, известен как Q.23. Сигнал представляет собой комбинацию из двух сигналов разной частоты.

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

---