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

Содержание:

Введение.

Целью данной курсовой работы является разработка средств и методов для решения задач по автоматизации обработки заявок в службу технической поддержки ООО «Грин Порт»

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

1. Затрудненная координация работы специалистов отдела ИТ, а именно – отсутствие закрепленных областей компетенции, что создает неразбериху и непонимание важности выполняемых функций; – не регламентированная форма подачи заявки создает риск потери заявки пользователя в общей массе заявок пользователей и поручений руководства; – жесткая зависимость работы компании от «ключевого» ИТ специалиста — если определенный тип проблем регулярно решает один и тот же сотрудник, то при его болезни или отпуске может остановиться работа всей компании. Все перечисленные недоработки приводят к попыткам самостоятельного решения пользователями возникающих вопросов, что часто вызывает еще более серьезные последствия.

2. Для оптимизации работы, специалистам отдела ИТ необходимо использовать систему автоматизации учета поступивших заявок — Service Desk. Service Desk обеспечивает единую точку контакта для пользователей (работников организации или «внешних» организаций, являющихся поставщиками каких-либо вспомогательных услуг (например, электропитания, внешних коммуникаций и т.д.)), сотрудников отдела ИТ и ИТ-услуг.

Организация внедрения системы Service Desk сводится до выполнения нескольких задач 1. Фиксация регламентов функционирования будущей системы. К ним относятся такие пункты как: − количество линий поддержки службы Service Desk; − распределение сотрудников по линиям поддержки; − способы приема заявок от пользователей (телефонный звонок на обозначенный номер, отправка письма на отдельный адрес электронной почты, служебная записка); − приоритеты обращений пользователей (остановка какого-либо бизнеспроцесса — наивысший приоритет, в то время как небольшая поломка принтера — низкий); − классификация обращений пользователей (различают запросы на обслуживание, инциденты, запросы на предоставление информации и т.п.); − система материальной и нематериальной мотивации сотрудников — KPI (специалисты рекомендуют строить мотивацию больше на поощрении сотрудников, а не на наказании, и использовать штрафные санкции только в критических ситуациях).

2. Так как все системы Service Desk построены на методологии ITIL, второй задачей является обучение сотрудников основам ITIL, для того, чтобы они знали, для чего нужен Service Desk и понимали принципы подобных систем. Рекомендуется не просто определить роли сотрудников по вышеуказанной схеме, но и физически разделить рабочие места всех групп иерархий между собой, так как если у первой линии чаще всего будут небольшие задачи и много звонков, то у последней линии задачи будут масштабнее и сложнее, что требует большей сосредоточенности. 3. Одной из важных задач является внедрение программного обеспечения, которое позволит контролировать процесс приема, распределения и выполнения заявок пользователей. 4. Введение SLA (соглашение об уровне услуг), каталога предоставляемых услуг, учета трудозатрат, помогают в более точном распределении и выполнении заявок, а также даст основу для ведения планирования ресурсов (как трудовых, так и технических). Возвращаясь к вопросу о внедрении программного обеспечения (далее — ПО), известно, что в среднем 21 % сотрудников компаний недовольны тем вы- 3 бором ПО [3], которое используется в их компании [4]. Под программным обеспечением подразумевается система Service Desk. Однако, в связи с тем, что существует большое количество систем Service Desk, для выбора такой системы необходимо проанализировать уже существующие системы Service Desk, после чего нужно правильно выбрать критерии для подбора такой системы и определить критерии отбора для внедрения в организацию. 5. Формирование call-центра с несколькими линиями технической поддержки ( 6. рис 1): Рис 1. Уровни поддержки систем Service Desk Существуют разные классификации систем Service Desk, например: 1. По уровням сложности call-центра [5]: − Центр приема сообщений (Call Center) — ориентация на организацию прием и регистрация большого количества заявок пользователей. − Диспетчерская помощи клиентам (Help Desk) — Call Center, разрешение инцидентов в максимально короткие сроки. − Сервис-диспетчерская (Service Desk) — Help Desk, учет влияния предоставляемых услуг на бизнес в целом. 2. По типу решения [6]: 4 − Самописные решения — используется чаще в компаниях с уникальными процессами. − Open Source Service Desk — бесплатные программные продукты, чаще всего не имеющие поддержку разработчика. − Специализированные решения — коммерческие программные продукты с автоматизацией широкого круга задач. − Профессиональные решения — корпоративные решения, автоматизирующие большое количество процессов. Имеют поддержку разработчика. Существуют различные методики принятия решений, такие как метод анализа иерархий, методы средних баллов, метод сценариев и прочие. Для выбора подходящей системы автоматизации учета поступивших заявок будем использовать метод анализа иерархий, потому что данный метод позволяет не только провести сбор необходимых данных и анализ проблемы, но так же он позволяет оценить противоречивость данных и ее минимизацию. Кроме того, метод анализа иерархий определяет важность учета каждого решения и каждого фактора, влияющего на приоритеты решений. Так же одним из плюсов метода является оценка устойчивости принимаемого решения [7]. Выбор системы был разбит на несколько шагов, первым из которых был сформирован набор критериев, подходящий для средней организации и такими функциями отдела ИТ, как поддержка компьютерной техники, поддержка и администрирование информационной системы (ИС), исполнение технических заданий на разработку и внедрения нового программного обеспечения. Выделены следующие критерии: − русскоязычный интерфейс; − поддержка системы разработчиками (она необходима, чтобы в случае выявления каких-либо проблем при использовании системы можно было обратиться в техническую поддержку разработчика); − шаблоны сообщений, обращений (в системе должна быть возможность создания набора различных шаблонов); − база знаний (как правило, необходима для решения проблемы пользователем самостоятельно или же для помощи в решении проблемы сотруднику отдела ИТ); − управление правами доступа; − формирование отчетов; − учет трудозатрат (данный учет позволит руководителю следить за нагрузкой специалистов отдела ИТ); − SLA+каталог услуг (SLA — соглашение об уровне предоставления услуги, позволяющее составить договор с обслуживаемой организацией, где будут прописаны все предоставляемые услуги, плановое время реакции и плановое время выполнения поступившей заявки по данной услуге); 5 − различные сценарии обработки заявок (так как рассматриваемый отдел ИТ занимается не только стандартными заявками, но и ведением проектов по доработкам программ, часто стандартные заявки перетекают в доработки, где регламентированы определенные этапы ведения проекта);

1. Технико-экономическая характеристика предметной области и предприятия

ООО «Грин Порт» является коммерческой организацией, предоставляющей транспортно-логистические услуги для заказчиков. Основным направлением деятельности компании является осуществление речных и морских перевозок грузов, организация контейнерных перевозок и управление несколькими складскими комплексами, обслуживающими данное направление деятельности. Заказчиками компании являются предприятия в основном аграрной и агрохимической отрасли. Целью компании является предоставление надежных и качественных транспортно-логистических услуг с учетом специфических требований заказчика, доставка грузов водным транспортом в кратчайшие сроки и по конкурентной цене. Компания начала свое развитие с предоставления транспортных услуг на базе речных перевозок сельскохозяйственных грузов, в дальнейшем развивая свою деятельность на осуществление морских перевозок и аренду складских комплексов для логистических нужд. Компания уже несколько лет является надежным транспортным партнером для ряда крупных сельскохозяйственных предприятий России, позволяя в кратчайшие сроки доставлять большие объемы груза с высокой рентабельностью, благодаря чему услуги компании востребованы на рынке и за последние несколько лет были продлены ранее заключенные контракты и заключены контракты с новыми заказчиками.

1. Организационная структура управления предприятием.

Организационно предприятие поделено на несколько основных подразделений

Управляющая компания

Подразделение осуществляющее фрахтовую деятельность

Логистическо-складское подразделение

В свою очередь управляющая компания делится на несколько подразделений

Дирекция

Коммерческий отдел

Управление перевозками

Управление логистикой и хранением грузов

Финансово-экономический отдел

Юридический отдел

Программно-технический отдел

Структурная схема предприятия:

В связи с использованием современных средств связи и программно-технических комплексов как в транспортно-логистическом секторе, так и в секторе управления предприятием, остро стоит вопрос в обеспечении доступности и исправности данных программно-технических средств в режиме 24/7 Все этапы ведения экономической деятельности предприятия тесно связаны с использованием автоматизированных рабочих мест пользователей, системами управления складом, базами данных обеспечивающими ведение складского и транспортного учета, базами данных обеспечивающими ведение бухгалтерского и налогового учета, системами электронной почты, службой мгновенных сообщений и телефонии. Для обеспечения высокой доступности данных сервисов в компании существует свой программно-технический отдел, в задачи которого входит поддержание работы и развитие существующих информационных сервисов. В свою очередь за работоспособность ключевых сервисов отвечают разные специалисты внутри отдела, что вызывает для пользователей информационных систем (ИС) определенные сложности в размещении заявки на техническое обслуживание в случае обнаружения в процессе работы технической или программной неисправности, не позволяющей эффективно выполнять должностные обязанности с использованием технических средств, так и распределение задач внутри отдела между специалистами. В связи с этим было принято решение внедрения программного комплекса по управлению заявками на предприятии. Кроме внедрения данной системы будет произведена реструктуризация отдела IT с целью оптимизации работы и разделения задач в соответствии со схемой 1.2

Схема 1.2 Программно-технический отдел

Проведение данной реструктуризации совместно с внедрением системы управления заявками позволит создать удобную прозрачную для пользователей систему обращений в отдел IT, минимизирует сроки реакции на заявку, создаст для пользователя удобную обратную связь по исполнению конкретной заявки или по дополнению её дополнительными сведениями, позволит разделить инциденты и обращения по категории сложности и выстроить цепочку по передаче заявок с разделением на уровни компетенций специалистов поддержки внутри отдела. В целом внедрение данной системы повысит качество работы ИТ-службы и ИС предприятия, удовлетворенность пользователей уровнем предоставляемых сервисов, сделает процесс работы ИТ-службы прозрачным для руководства компании, повысит экономическую рентабельность работы ИТ-службы предприятия. Для упрощения постановки задачи и разработки решения по внедрению системы поддержки на Схеме 1.3 представлена укрупненная схема отдела IT с разделением на категории специалистов и на уровни поддержки.

Схема 1.3

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

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

Входные потоки

Обращение пользователя посредством создания заявки через WEB-портал

Обращение пользователя по электронной почте

Обращение пользователя по телефону

Дополнительные сведения по заявке (описание проблемы, информационной системы с которой произошла проблема, указание срочности выполнения задачи)

Выходные потоки

Присвоение обращению уникального для данной системы идентификатора (номера)

Фиксация статуса заявки и назначения группы исполнителей

Назначение приоритета срочности заявки

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

Общая структура системы в формате IDEF0 представлена на схеме 1.4

Общая схема работы системы в виде модели IDEF0

Декомпозиция 1-го уровня:

Решаемые задачи в рамках использования, оценка критериев эффективности, расчет основных показателей

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

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

Общее кол-во выполненных заявок

Общее кол-во просроченных по срокам закрытия заявок

Общее кол-во повторно открытых заявок

Общее кол-во не выполненных заявок

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

Распределение заявок по сервисам (информационным системам)

Распределение заявок по сотрудникам (инициаторам заявок)

Распределение заявок по исполнителям заявок

На основе данных показателей можно произвести анализ основных критериев эффективности. Для качественного и количественного учета уровня предоставляемых услуг для предприятия ООО «ГринПорт» был проведен анализ информационных систем по степени критичности для бизнеса и, вероятных финансовых и репутационных потерях, в случае недоступности информационных систем и сервисов. На основе данного анализа все предоставляемые сервисы были разделены на 3 группы с соответствующим временем реагирования на заявку, установкой приоритета заявки, присвоением ей статуса в системе учета заявок и её эскалацией в системе после поступления заявки во входной поток системы. Определены следующие групп ИС (информационных систем):

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-телефонии предприятия, что позволяет прозрачно взаимодействовать пользователю с системой учета заявок посредством голосового меню и нажатий клавиш.

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

Схема взаимодейтсвия с голосовым меню (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 с.

1. Необходимо прокомментировать каждый критерий ↑