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

Более подробно схема взаимодействия указана на рисунке:

Схема взаимодейтсвия с голосовым меню (IVR) с помощью телефонных кодов DTMF

Модуль сбора и отображения статистики

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

Данный модуль состоит из следующих компонентов:

Модуль сбора статистики

Аналитический модуль

Модуль прогнозирования

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

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

• Процент созданных в системе заявок за выбранный период времени
• Процент положительно решенных заявок за выбранный период времени
• Процент не решенных заявок за выбранный период времени
• Процент повторно открытых заявок за выбранный период времени
• Процент заявок по конкретной ИС
• Процент заявок по конкретному пользователю
• Распределение заявок по исполнителям

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

3. Анализ эффективности внедрения и работы системы. Выводы.

Рассмотрим модель до внедрения информационной системы.

По данным наблюдений, проводимых в течение трех месяцев, средняя частота поступления обращений λ=5заявок/час, при этом диспетчер комфортно справляется с большим числом заявок μ=6заявок/час, среднее время обслуживания одного сотрудника, подавшего заявку x=1/5= 0,167 часа. Диспетчер работает один, так что число каналов m=1.

---

Найдем нагрузку на систему: ρ=λ/(mμ) = 0,83.

Найдем вероятность простоя по формуле P₀= 1-ρ:P₀=0,17.

Найдем среднюю длину очереди по формуле:

Получим: q=4,17заявки.

Отдел технической поддержки принимает на обслуживание все поступающие заявки (отказов в обслуживании нет). Поэтому P_отк=0, P_обсл=1.

Найдем остальные характеристики системы по формулам из справочной литературы [2]:

Коэффициент загрузки

,U=0,83;

Среднее число заявок в обслуживании

,S=0,83заявок;

Среднее число заявок в СМО

,k=5заявок;

Пропускная способность СМО

,γ=5заявок/час;

Среднее время пребывания заявки в очереди

,w=0,417 часа;

Среднее время пребывания заявки в системе

,t=0,5часа.

Проанализируем полученные характеристики системы.

Helpdesk загружен на 83%, т.е. занят обслуживанием сотрудников, обратившихся с неисправностями в течение 83% всего времени своей работы. В течение 17% времени диспетчер простаивает из-за отсутствия заявок. Таким образом, загрузка диспетчера достаточно высока. Такую загрузку можно считать нормальной. Однако дальнейшее увеличение загрузки нежелательно.

В среднем в очереди находится 4,17 заявки ,а в пуле заявок (т.е. в очереди и на обслуживании) – 5заявок. Диспетчер обслуживает в среднем 5 заявоквчас, т.е. все поступающие заявки. Время от информирования диспетчера о поступившей заявке до начала ее обслуживания (т.е. время пребывания заявки в очереди) составляет в среднем 0,417 часа. Время от поступлени язаявки до окончания ее обслуживания (время пребывания заявки в ожидании решения об исполнении) составляет в среднем0,5 часа. Если сравнить это время с длительностью рабочего дня и учесть тот факт, что до момента появления на месте специалиста может пройти еще больше времени, то данный показатель можно считать неудовлетворительным.

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

---

Таким образом, новые показатели для системы составляют:

средняя частота поступления обращений λ=5заявок/час,

интенсивность обслуживания заявок μ=12заявок/час, среднее время обслуживания одного сотрудника, подавшего заявку x=1/12 = 0,083часа.Будем считать, что число каналов m=1.

Найдем нагрузку на СМО: ρ=λ/(mμ) = 0,42.

Найдем вероятность простоя по формуле P₀= 1-ρ:P₀=0,58.

Найдем среднюю длину очереди по формуле:

.

Получим:q=0,152заявки.

Отдел технической поддержки принимает на обслуживание все поступающие заявки(отказов в обслуживании нет). Поэтому P_отк=0,P_обсл=1.

Найдем остальные характеристики СМО по формулам из справочной литературы []:Коэффициент загрузки

,U=0,42;

Среднее число заявок в обслуживании

,S=0,42заявок;

Среднее число заявок в СМО

,k=0,47заявок;

Пропускная способность СМО

,γ=5заявок/час;

Среднее время пребывания заявки в очереди

, w=0,03часа;

Среднее время пребывания заявки в СМО

,t=0,094часа.

Проанализируем полученные характеристики системы.

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

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

Приложение 1

Список литературы и источники:

1. Аалдерс Роб. ИТ аутсорсинг. Практическое руководство. Альпина Бизнес Букс, 2004 г. 300 стр.
2. Агафонов В.Н. Спецификация программ: понятийные средства и их организация. — Новосибирск: Наука, 1987. — 240 с.
3. Агафонов В.А. Анализ стратегий и разработка комплексных программ.- М.: Наука, 1990.- 216с.
4. Аджиев В. Объектная ориентация: философия и футурология. Открытые системы, N 06 1996 г.
5. Аджиев В. MS: корпоративная культура разработки ПО. Открытые системы, N 01 1998 г.
6. Альпина Паблишер. Управление проектом по созданию интернет-сайта. Альпина Паблишер, 2001 г. 337 стр.
7. Андон Ф.И., Коваль Г.И., Коротун Т.М., Суслов В.Ю.; [Отв. ред. И.В.Сергиенко]. Основы инженерии качества программных систем / НАН Украины. Ин-т прогр. систем. — К.: Изд. дом «Академпериодика», 2002. — 502 с.: ил., табл.
8. Ансофф Игорь. Новая корпоративная стратегия. Серия: Теория и практика менеджмента. Издательство: Питер, 1999 г. 416 стр.
9. Армстронг М., Барон А. Performance Management. Управление эффективностью работы. Performance Management: The New Realities. Серия: Developing Practice. Издательство: Hippo, 2005 г.- 384 стр.
10. Арчибальд Р.Д. Управление высокотехнологичными программами и проектами / Пер. с анг. Мамонтова Е.В.; под ред. Баженова А.Д., Арсеньева О.А. ДМК Пресс; АйТи, 2004.- 463 с
11. Ауэр Кент, Миллер Рой. Экстремальное программирование: постановка процесса. С первых шагов и до победного конца Planning Extreme Programming. Серия: Библиотека программиста. Издательство: Питер, 2003 г. — 368 стр.
12. Ахмед Х.З. Разработка корпоративных Java приложений с помощью J2EE и UML/ Пеp. с англ.А.В.Высоцкого.- М.: Вильямс, 2002.- 267 с.

---