VII Международная студенческая научная конференция Студенческий научный форум - 2015

ВВЕДЕНИЕ

В настоящее время бизнес всецело зависит от информационно-коммуникационных технологий. Информационные технологии позволяют автоматизировать работу, упростить задачи, помогают собирать статистические данные, на основе этих данных принимать решения, а также пользоваться электронной почтой, интернетом, удаленно взаимодействовать с партнерами и клиентами. Внедрение и эксплуатация информационной системы для автоматизации бизнес-процессов компании является сложной задачей и требует специальных знаний в области информационных технологий. ИТ-отдел внутри компании позволяет решить эту задачу, но ИТ-отдел также подразделение на содержание, которого уходит существенная часть бюджета компании. Затраты становятся больше, если ИТ-отдел развернут в самой компании. Преимуществом является то, что собственный ИТ-отдел отличается пониманием бизнес-процессов компании, а не только наличием технических решений, которые может дать компания аутсорсер. Но в последнее время, чтобы повысить свою конкурентоспособность компании аутсорсеры стремятся подстроиться под нужды бизнеса. Поэтому стал широко развиваться аутсорсинг. Идет делегирование определенных сфер деятельности компании, которые не связаны с основными задачами, стороннему предприятию, специализирующемуся как раз на таких задачах. Аутсорсеры руководствуются рекомендациями библиотеки ITIL при построении своего бизнеса. После внедрения информационной системы, либо после развертывания услуг компании аутсорсера в качестве ИТ-подразделения в организации идет эксплуатация информационной системы и применение услуг аутсорсинга в бизнесе. Для устранения проблем, возникающих в процессе работы в информационной системе внедряется Service Desk. Служба технической поддержки является сервисной структурой и осуществляет поддержку пользователей в ряде услуг, которые помогут устранить неполадки в работе с компьютерными аппаратными средствами, программным обеспечением. Перед службой технической поддержки ставится задача обеспечения доступности поддерживаемых информационных систем и своевременного разрешения инцидентов. Существует определенная модель решения инцидентов, но она недостаточно эффективна при поступлении большого количества заявок. В среднем, каждая 5-я заявка из числа принятых звонков не регистрируется в системе.

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

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

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

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

Задачи совершенствования инцидент-менеджмента рассмотрены в работах авторов: Тушавин В. А, Иванов Д. Б., Больных А. А. и др.

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

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

Для достижения поставленной цели в работе сформулированы и решены следующие задачи:

• Анализ существующей системы управления инцидентами;

• Разработка предложений по повышению эффективности функционирования службы технической поддержки;

• Разработка методики повышения эффективности инцидент-менеджмента;

• Оценка целевой эффективности разработанных предложений.

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

Предметом исследования являются процессы функционирования системы управления технической поддержки.

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

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

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

– разработана методика повышения эффективности инцидент-менеджмента;

– проведена оценка целевой эффективности разработанных предложений.

На защиту выносятся:

• Математическая модель управления инцидентами;

• Алгоритм решения задачи нахождения минимального количества каналов обработки заявок при заданных ограничениях;

• Алгоритм управления инцидентами;

• Методика повышения эффективности инцидент-менеджмента;

Теоретическая и практическая значимость исследования.

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

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

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

Методы исследования.

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

Основные полученные результаты.

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

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

Публикации.

По теме диссертационного исследования опубликованы три статьи:

«Автоматизация инцидент-менеджмента на основе системы поддержки принятия решений» опубликована в НИИ «Восход» в Сборнике статей Научно-практической конференции «Современные информационные технологии в управлении и образовании»;

«Совершенствование системы управления функционированием службы технической поддержки IT- компании» опубликована научным центром «Аэтерна» (г. Уфа) в Сборнике статей Международной научно-практической конференции «Тенденции развития технических наук»;

«Предложения по совершенствованию системы управления инцидентами» в Сборнике трудов Международной научно-практической конференции«Информационные и коммуникационные технологии в образовании, науке и производстве» (г. Протвино, Московской области).

Структура и объем работы.

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

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

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

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

Каждая глава заканчивается кратким выводом.

В заключении кратко сформулированы основные результаты работы.

ГЛАВА 1. АНАЛИЗ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ В ИНФОРМАЦИОННЫХ СИСТЕМАХ

В данной главе проведен анализ рекомендаций ITIL и ITSM, описан процесс управления инцидентами. Проанализирована существующая система управления инцидентами, подробно рассмотрена модель системы управления инцидентами, выявлены недостатки в процессе управления инцидентами.

1.1. Анализ применения рекомендаций ITIL и ITSM в процессе управления инцидентами.

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

Service Desk – специализированная функциональная единица, ориентированная на обработку специфических сервисных событий, поступающих в форме обращений пользователей или сообщений систем мониторинга. Также Service Desk – единая точка контакта (Single Point Of Contact) между поставщиком сервисов и пользователями.

В настоящее время Service Desk позволяет адаптировать бизнес к быстро меняющимся условиям рыночной среды за счет информации получаемой в ходе обработки собираемых статистических данных.

Главная цель Service Desk – восстановить тот уровень сервиса, который был оговорен в Соглашении об уровне сервиса (Service Level Agreement, SLA) SLA как можно скорее.

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

Схематически процесс работы Service Desk выглядит как на рисунке 1, представленном ниже:

Рис. 1. Процесс работы Service Desk.

Service Desk, согласно сервисному подходу, является звеном, помогающим правильно организовать взаимоотношение между пользователями и ИТ-подразделением.

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

– пользователям удобно обращаться в единую горячую линию;

– при увеличении потока обращений от пользователей появляется необходимость разделять функции специалистов;

– появляется необходимость в координации совместных усилий различных ИТ-подразделений;

– появляется необходимость в формировании отчетности и сборе статистики по всем обращениям, времени и качеству решений.

В отличие от технических специалистов ИТ-подразделения сотрудники Service Desk ориентированы на общение с пользователями. Служба технической поддержки берет на себя решение проблемы пользователя [1].

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

Преимуществами Service Desk является повышение уровня контроля за работой специалистов, так как, согласно ITIL, операторы Service Desk координируют работу специалистов, контролируют время выполнения работ, оценивают качество решения обращения специалистами на основании оценки пользователей. Благодаря этому большинство компаний для увеличения производительности и повышения эффективности деятельности своего бизнеса организуют работу службы технической поддержки исходя из библиотеки передового опыта IT Infrastructure Library.

Как известно, ITIL - это набор рекомендаций по лучшим практикам в управлении ИТ-услугами (ITSM). ITIL принадлежит британскому правительственному агентству Office of Government Commerce (OGC) и представляет собой набор публикаций, содержащих рекомендации по организации предоставления качественных ИТ-услуг, а также процессов и компонентов, необходимых для их поддержки [2].

Набор рекомендаций был разработан в конце 80-х годов и состоял из 40 томов, но на сегодняшний день доступны только несколько. В ITIL v.2 семь книг:

• Поддержка услуг (Service Support);

• Предоставление услуг (Service Delivery);

• Планирование внедрения управления услугами (Planning to Implement Service Management);

• Управление приложениями (Application Management);

• Управление инфраструктурой информационно-коммуникационных технологий (ICT Infrastructure Management);

• Управление безопасностью (Security Management);

• Бизнес-перспектива (The Business Perspective);

• Управление конфигурациями ПО (Software Asset Management).

По ITIL v.3:

• Стратегия услуг (Service Strategy);

• Проектирование услуг (Service Design);

• Преобразование услуг (Service Transition);

• Эксплуатация услуг (Service Operation);

• Постоянное улучшение услуг (Continual Service Improvement).

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

IT Service Management (ITSM) представляет собой внедрение и управление качественными ИТ-услугами, которые соответствуют требованиям бизнеса. Управление ИТ-услугами (ITSM) реализуется поставщиками ИТ-услуг путем использования наиболее оптимального сочетания людей, процессов и информационных технологий [2].

Существуют несколько базовых процессов при управлении ИТ-услугами: процесс управления инцидентами; процесс управления проблемами; процесс управления конфигурациями; процесс управления изменениями; процесс управления релизами; процесс управления уровнем услуг; процесс управления мощностями; процесс управления доступностью; процесс управления непрерывностью; процесс управления финансами.

Одним из базовых процессов, обеспечивающих поддержку и предоставление ИТ-услуг, является процесс управления инцидентами.

Под инцидентом понимается (от лат. incidens – случай, происшествие (обычно неприятное) столкновение с неприятным случаем) любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги. В свою очередь, управление инцидентами - есть деятельность по восстановлению нормального обслуживания с минимальными задержками и влиянием на бизнес-операции [2].

На данный момент работа ИТ-службы устроена таким образом, что процесс управления инцидентами включает в себя такие этапы как:

1. Выявление и регистрация инцидентов (Acceptance and Recording).

На этом этапе в Service Desk принимается сообщение о возникшей проблеме и создается запись о ней в системе управления инцидентами.

1. Классификация и начальная поддержка (Classification and Initial Support).

Заявке присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, срок по SLA и т.п. Пользователю может быть предложено возможное решение – консультация. В системе управления инцидентами создается запрос на Обслуживание (Service Request), осуществляется поиск ответа в Базе знаний, проверяется, не является ли инцидент уже известной ошибкой, нет ли для него решения.

1. Исследование и диагностика (Investigation and Diagnosis).

При отсутствии известного решения, производится исследование инцидента с целью оперативного восстановления сервиса.

1. Решение и восстановление (Resolution and Recovery).

Если решение найдено, то работа может быть восстановлена.

1. Закрытие инцидента (Closure).

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

1. Мониторинг хода работ и отслеживание (Progress monitoring and Tracking).

Весь цикл обработки инцидента контролируется – идет мониторинг ошибок. Если инцидент не может быть разрешен вовремя, то производится эскалация. В завершении производится оценка полученного ущерба [3].

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

Современные системы Service Desk способны управлять, контролировать и отслеживать запросы на обслуживание, соблюдение условий контракта, людские ресурсы и последовательности работ. Эти системы интегрируются с остальными важными компонентами совокупной системы управления ИТ-ресурсами (в том числе с рекомендуемыми ITIL — Управлением изменениями, Конфигурированием и Учетом активов, Управлением ценой, Непрерывностью бизнеса, Планированием возможностей, Управлением сетями и т.д.).

К наиболее развитым системам, предназначенным для реализации Service Desk в организациях среднего и крупного размера, относят такие системы управления инцидентами как:

– CA Service Desk Manager;

– HP Open View Service Desk;

– Tivoli Service Request Manager.

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

– возможность интеграции с остальными решениями по управлению различными элементами ИТ-инфраструктуры (сетями, серверами, рабочими станциями приложениями и т.д.);

– условия предоставляемой поддержки (ее полнота и доступность, а также возможность привлечения консультантов из компаний, специализирующихся на внедрении этих систем).

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

Анализ применения систем управления инцидентами показал, что среди малого и среднего бизнеса распространенными являются такие системы как: TerraSoft Service Desk, Naumen Service Desk, «Итилиум», HPService Management.

TerraSoft Service Desk помогает сократить время на обработку обращений и заявок. Система автоматически определяет время, необходимое на выполнение каждого запроса на изменение, анализирует загрузку специалистов и создает задачи.

Naumen Service Desk доступен как SaaS сервис. Это популярное отечественное ИТ-решение переходит на схему SaaS. Naumen Service Desk - ведущая ITSM система на российском рынке. Она позволяет отслеживать ИТ-инфраструктуру, принимать заявки от пользователей, контролировать их решение, а также управлять обновлениями, конфигурациями, уровнем сервиса и всеми теми процессами, которые описаны в библиотеке ITIL. Для пользователей доступен клиентский портал с личным кабинетом, где можно оставлять заявки, контролировать их статус, общаться с сотрудниками технической поддержки и читать базу знаний.

«Итилиум» система управления инцидентами предназначенная для автоматизации процессов библиотеки ITIL. Система «Итилиум» разработана компанией «Деснол Софт» на базе платформы «1С: Предприятие 8». Главная особенность системы – способность в краткие сроки оптимизировать ИТ-процессы компании.

HP Service Management. Постоянно расширяется портфель решений для управления услугами, которые позволят ИТ-организациям воспользоваться дополнительными возможностями обновленной библиотеки ITIL версии 3.

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

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

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

В первую очередь, это система распределения звонков. Звонки, поступающие в службу технической поддержки, распределяются между операторами нормировано, например, если один оператор уже принимал звонок, то следующий по очереди звонок поступает на второго оператора. При подключении автоматизированного рабочего места в телефонную линию, оператора регистрируют в автоматической телефонной станции (АТС), чаще всего организации используют АТС от фирм Cisco, Avaya, Asterisk, Infinity. Если входящие вызовы не могут быть немедленно приняты оператором, то функция приоритетной очереди помещает их в упорядоченную очередь оператора. При большом потоке обращений образуется очередь заявок на линии.

Подходы по управлению процессами в ITSM реализуются с помощью ITIL, согласно которой инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и запросы на обслуживание (обращения) [3].

Запрос на обслуживание (обращение) – это запрос от пользователя на поддержку, предоставление информации, не являющийся сбоем ИТ-инфраструктуры [2].

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

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

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

Суть алгоритма заключается в следующем. Каждое обращение и инцидент регистрируются для того, чтобы их можно было отследить, проверить и обновить в процессе работы алгоритма. Если в базе знаний решение по возникшему инциденту есть, пользователю сообщают соответствующее решение, и на этом обработка инцидента завершается. В случае отсутствия решения по возникшему инциденту он направляется на вторую линию техподдержки: назначается исполнитель – специалист, который выполняет работу по устранению инцидента. Затем специалист 1-й линии поддержки оповещает пользователя об устранении ошибки. Ожидается ответ от пользователя. В случае отрицательного результата, решение отправляется на доработку исполнителю. А в случае положительного результата инцидент закрывается и считается отработанным. На рисунке 2 представлен алгоритм работы с инцидентами в службе технической поддержки на первой и второй линии.

Рис. 2. Существующий алгоритм работы с инцидентами в службе технической поддержки на первой и второй линии.

В системе управления инцидентами различают понятия обращения и инцидента.

Обращение – это заявка в системе управления инцидентами, зарегистрированное по факту обращения пользователя в ИТ-подразделение.

Инцидент – это заявка о нештатной ситуации в инфраструктуре, которая привела или может привести к неработоспособности или снижению качества предоставления услуг [2]. Работу над инцидентом проводят специалисты 2-й линии поддержки.

Для анализа функционирования службы технической поддержки внутри информационной системы управления инцидентами, на рисунках 3 и 4 представлены жизненные циклы обработки Обращения и Инцидента. В овалах отражены статусы обращений и инцидентов. Статусы меняются по ходу выполнения работ над обращением и инцидентом. Линии указывают, на то какие процессы выполняются специалистом 1-й линии вручную (при действии в информационной системе управления инцидентами).

Рис. 3. Жизненный цикл обработки Обращения.	Рис. 4. Жизненный цикл обработки Инцидента.

Рассмотрим рисунок 3. Жизненный цикл обработки Обращения. Процесс обработки Обращения начинается со статуса «новое». В этом статусе заявка появляется в системе управления инцидентами при получении от пользователя электронного письма с описанием проблемы или при звонке в службу технической поддержки.

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

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

Когда специалист начинает работать с обращением или с инцидентом у них изменяется статус – «в работе». После выполнения необходимых работ обращение проходит контроль оператора и переходит в статус «выполнено».

Обращения подразделяются на категории: консультация, запрос на обслуживание, запрос на изменение, обращение не по адресу, отзыв по качеству, инцидент. В соответствии с требованиями Соглашения об уровне сервиса (Service Level Agreement, SLA), которые используются, чтобы зафиксировать, кому предоставляется сервис, в какие сроки и в какую очередь, система рассчитывает ориентировочные сроки выполнения зарегистрированных обращений.

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

Рис. 5. Существующая модель процесса управления инцидентами.

Процесс управления инцидентами сфокусирован на скорейшем восстановлении прерванного сервиса. На рисунке 5 показана существующая модель процесса управления инцидентами.

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

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

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

При анализе существующей модели управления инцидентами (рис.5) выявлены следующие недостатки:

– образование очереди на линии при большом потоке звонков (заявок);

– ограниченное время для консультирования и обработки обращений операторами, Регистрация и классификация обращений занимает значительное время;

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

– неструктурированность Базы знаний и ее несвоевременное обновление. При попытке оказания первоначальной поддержки ориентироваться в неструктурированной Базе знаний по предмету консультации крайне сложно;

– передача инцидента на 2-й уровень поддержки без его разрешения на 1-м уровне.

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

– возникновение очереди необслуженных инцидентов на 2-й линии поддержки. Большой процент направленных на 2-ю линии инцидентов — это отрицательный и крайне низкий показатель качества работы первой линии поддержки, которая должна закрывать не менее 80% всех поступающих обращений.

– превышение установленных сроков обслуживания инцидента в соответствии с Соглашением об уровне оказания услуг (SLA). Каждый инцидент, зарегистрированный в информационной системе управления инцидентами имеет свои сроки выполнения. В соглашении об уровне предоставления услуг (англ. Service Level Agreement (SLA)) указаны уровни качества предоставления услуг, сроки восстановления и время доступности предоставляемых услуг. При управлении инцидентами необходимо придерживаться сроков разрешения инцидента согласно срокам, указанным в Соглашении об уровне оказания услуг (SLA).

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

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

Большинство компаний применяет эталонную модель управления инцидентами, так как процесс управления инцидентами является единым для всех ИТ-подразделений.

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

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

1. телефон;

2. электронная почта;

3. система электронного документооборота;

4. web-форма;

5. внешняя система;

6. служебная записка.

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

1. Инцидент;

2. Запрос на обслуживание;

3. Запрос на изменение;

4. Запрос информации;

5. Отзыв по качеству;

6. Не по адресу.

Все ИТ-специалисты кроме Диспетчеров Контакт Центра (операторы) и Инженеров Центра компетенции (специалисты) входят в рабочие группы. Один ИТ-специалист может входить в состав нескольких рабочих групп. В состав Контакт Центра входят: Руководитель; Диспетчеры. В состав Центра компетенции входят: Координатор; Инженеры. В состав рабочей группы входят: Координатор группы; Исполнители.

Существуют основные правила обработки Обращений и Инцидентов:

1. Диспетчер (оператор) принимает, регистрирует Обращения, выполняет первичную классификацию и получает подтверждение пользователя о выполнении Обращения.

2. Специалист 1й линии технической поддержки является ответственным за классификацию или выполнение Обращений и направление Инцидентов в работу в рабочую группу к специалистам 2-й линии;

3. Инженер Центра компетенции отвечает за контроль сроков исполнения и контроль корректности оформления и сроков выполнения Обращений из своей зоны ответственности;

4. Исполнитель (специалист 2-й линии технической поддержки) является ответственным за исполнение назначенного на него Инцидента и корректность его оформления;

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

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

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

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

• среднее количество пропущенных звонков из числа поступивших звонков;

• количество незарегистрированных заявок из числа принятых звонков;

• количество заявок закрытых с Базой знаний и без использования Базы знаний;

• количество выполненных заявок по линиям технической поддержки;

• количество закрытых обращений с соблюдением крайних сроков.

Таблица 1.

Среднее количество пропущенных звонков из числа поступивших звонков.

Неделя № 40		Неделя № 41		Неделя № 42		Неделя № 43		За весь период
Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено
542	22	453	20	677	27	711	21	2383	90

Таблица 2.

Количество незарегистрированных заявок из числа принятых звонков.

Неделя № 40		Неделя № 41		Неделя № 42		Неделя № 43		За весь период
Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.
520	106	433	109	650	53	690	59	2293	327

Таблица 3.

Количество заявок закрытых с Базой знаний и без использования Базы знаний.

Неделя № 40		Неделя № 41		Неделя № 42		Неделя № 43		Всего за период	Всего за период
Без БЗ	С БЗ	Без БЗ	С БЗ	Без БЗ	С БЗ	Без БЗ	С БЗ	Без БЗ	С БЗ
438	46	614	24	383	22	368	30	1803	122

Таблица 4.

Количество выполненных заявок по линиям технической поддержки.

Неделя № 40		Неделя № 41		Неделя № 42		Неделя № 43		Всего за период	Всего за период
1-я л.	2-я л.	1-я л.	2-я л.	1-я л.	2-я л.	1-я л.	2-я л.	1-я л.	2-я л.
83	401	73	565	87	318	103	295	346	1579

Таблица 5.

Количество закрытых обращений с соблюдением крайних сроков.

"Да" - обращение просрочено; "Нет" - обращение не просрочено										Всего
Недели								Открытые обращения на конец периода
№ 40		№ 41		№ 42		№ 43
Да	Нет	Да	Нет	Да	Нет	Да	Нет	Да	Нет	Да	Нет
3	481	15	623	4	401	18	380	106	667	146	2552

Диаграмма 1 к табл. 1. Среднее количество пропущенных звонков из числа поступивших звонков.

Диаграмма 2 к табл. 2. Количество незарегистрированных заявок из числа принятых звонков.

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

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

Круговая диаграмма 5 к табл. 5. Количество закрытых обращений с соблюдением крайних сроков.

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

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

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

В круговой диаграмме 3 к таблице 3 видна доля заявок закрытых с Базой знаний и без использования Базы знаний. Из-за неструктурированности Базы знаний возникает низкий процент закрытия обращений первой линией, низкий процент использования Базы знаний.

В круговой диаграмме 4 к таблице 4 отображено количество выполненных заявок по линиям технической поддержки. Из-за нехватки времени и сложного поиска ответа в Базе знаний вытекает проблема маршрутизации большинства обращений на вторую линию, что отрицательно сказывается на качестве работы первой линии поддержки, которая должна закрывать 80% всех поступающих обращений. По диаграмме 4 к таблице 4 видно, что первая линия закрывает максимум заявок (25%), поступающих в службу технической поддержки.

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

Вывод по первой главе.

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

Основным показателем эффективной работы первой линии технической поддержки является успешное разрешение 80% инцидентов на первой линии за счет использования базы знаний, также снижение количества пропущенных звонков и незарегистрированных инцидентов. При анализе существующей модели управления инцидентами были выявлены такие недостатки как: ограниченное время для консультирования и обработки обращений; образование очереди при большом потоке заявок; неструктурированность Базы знаний; большой процент инцидентов, направленных на 2-ю линию технической поддержки; превышение установленных сроков обслуживания инцидента.

Для проведения точного анализа взяты результаты работы службы технической поддержки, которые показали, что среднее количество пропущенных звонков из числа поступивших звонков составляет 3,77%, количество незарегистрированных заявок из числа принятых звонков – 5,7%, а количество заявок, у которых истек срок выполнения – 81%.

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

ГЛАВА 2. РАЗРАБОТКА ПРЕДЛОЖЕНИЙ ПО ПОВЫШЕНИЮ ЭФФЕКТИВНОСТИ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ.

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

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

– обследование — описание и анализ ситуации «как есть» по процессу или отдельным процедурам управления инцидентами;

– логическое проектирование — построение концептуальной модели процесса управления инцидентами;

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

Результаты анализа легли в основу построения математической модели.

2.1. Разработка концептуальной модели управления инцидентами.

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

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

Способы обращения Пользователя в Контакт Центр:

1. Пользователь может обратиться в Контакт Центр по телефону.

2. Пользователь может обратиться в Контакт Центр с обращением на бумажном носителе.

3. Пользователь может обратиться в Контакт Центр по электронной почте. При необходимости обращение направляется с вложением/прикреплением.

4. Пользователь может обратиться в Контакт Центр через web-форму.

5. Пользователь может обратиться в Контакт Центр через систему документооборота (СЭД). Документ должен соответствовать формату, установленному внутренними регламентирующими документами.

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

Рассмотрим способ обращения по телефону, так как большинство заявок поступает по звонку от пользователя. Звонок регистрируется в автоматической телефонной станции службы технической поддержки. Пользователь в это время слышит автоинформатор, который распределяет звонки по тематике вопроса. Автоинформатор – система автоматического воспроизведения сообщений по телефону, который выполняет функцию распределения звонков по тематике вопроса. Также автоинформатор позволяет заменить операторов, чтобы звонок пользователя не переводился от одного оператора к другому. Автоинформатор подключен к АТС и в момент, когда звонит пользователь, воспроизводится информационное сообщение. Для того, чтобы записать такое сообщение используется функция «голосовое меню» — это автоматическая навигация по услугам и контактам компании. Меню поможет клиенту найти нужную информацию, прослушать важные сообщения компании, обратиться с вопросом к конкретному специалисту. Настроить распределение входящих вызовов можно: переключением на внутренние номера (подразделений, отделов фирмы), на любые городские, а также сотовые номера сотрудников.

Например, в автоинформатор может быть загружено сообщение, содержащее такой текст: «Вас приветствует компания «Название компании». Спасибо за звонок. Для соединения с оператором нажмите 1. Если Вам нужна консультация по работе в системе, нажмите 2. Если вас интересуют вопросы, связанные с ремонтом оборудования, нажмите 3. Для того чтобы оставить заявку о сбое в системе, либо об ошибках работы системы, нажмите 4. Если вы хотите оставить звуковое сообщение, дождитесь звукового сигнала».

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

Телефонных линий несколько и за каждой линией закреплена рабочая группа операторов (Диспетчеров Контакт Центра). Очередь может быть ограничена и тогда, если все операторы заняты, то заявка получит отказ в обслуживании. Распределение звонков по операторам производится через специальную систему АТС, которая переводит звонок. Если оператор свободен, то звонок принимается. Но если все операторы заняты, автоинформатор сообщает пользователю: «В настоящее время все операторы заняты. Оставайтесь на линии, Ваш звонок очень важен для нас. Если вы хотите оставить звуковое сообщение, дождитесь звукового сигнала». После звукового сигнала у пользователя есть возможность оставить заявку через голосовую почту и позже операторы, прослушивающие голосовые сообщения свяжутся с ним.

В случае, когда оператор принимает звонок, по схеме видно, что идет регистрация заявки в информационной системе управления инцидентами.

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

- контактное лицо;

- название и адрес организации;

- контактные данные (телефон, электронная почта);

- способ обратной связи (телефон, электронная почта);

- суть проблемы;

- название системы или оборудования, с которым связана проблема (с указанием модели, марки оборудования и прочих данных);

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

- категория заявки (консультация, запрос на обслуживание, запрос на изменение, отзыв по качеству, не по адресу);

- направление (заполняется в соответствии с тематикой вопроса);

- вид услуги;

- приоритет заявки (критический, высокий, средний, низкий);

- срок, отведенный на решение заявки согласно SLA;

Далее, оператор осуществляет поиск информации в Базе знаний.

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

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

База прецедентов – это описание проблемы или ситуации в совокупности с подробным указанием действий, предпринимаемых в данной ситуации или для решения данной проблемы.

База прецедентов обновляется специалистами 2-й линии поддержки.

Схематически процесс обновления приведен на рисунке 6.

Рис. 6. Цикл обновления Базы прецедентов.

Рис.7 . Концептуальная модель процесса управления инцидентами.

Если специалист технической поддержки найдет ответ в Базе прецедентов, то осуществляется консультация по Базе прецедентов. Если ответ не найден ни в Базе знаний, ни в Базе прецедентов, то заявка передается специалистам 2-й линии технической поддержки (инженерам). Инженеры проводят диагностику, восстанавливают сервис, устраняют инцидент. После восстановления сервиса специалисты выходят на связь с пользователем и сообщают о восстановлении сервиса.

2.2. Разработка математической модели управления инцидентами.

Анализ процессов организации управления инцидентами в существующей структуре службы технической поддержки показал, что в ее состав входят: телефонный узел, автоматизированные рабочие места операторов первой линии и инженеров второй линии технической поддержки. Обращения пользователей в рассмотренной системе фиксируются через систему управления инцидентами Hewlett-Packard Service Manager (HPSM), которая предназначена для автоматизации процессов службы технической поддержки и управления IT-услугами.

В целях устранения недостатков, выявленных в первой главе, разработана математическая модель управления инцидентами, которая позволила решить задачу совершенствования функционирования системы управления службы технической поддержки. При достаточно большом потоке звонков (заявок), связанных с ухудшением характеристик функционирования информационной системы возникает необходимость оперативного реагирования на заявки пользователей с целью минимизации их потерь и устранения. Один из подходов для решения поставленной задачи связан с применением рекомендаций ITIL в системе управления службы технической поддержки (СУСТП), которые позволяют существенно уменьшить время реакции на поступающие заявки от реальных пользователей за счет нахождения минимального количества каналов обработки заявок при заданных ограничениях [26].

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

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

Заявкой называется спрос на удовлетворение какой-либо потребности. Удовлетворение спроса называется обслуживанием заявки. Поступление заявки в систему массового обслуживания (СМО) является событием. Последовательность событий, состоящих в поступлении заявок в СМО, есть входящий поток заявок. В зависимости от поведения заявки в СМО различают СМО с отказами и СМО с очередью (или с ожиданием). В СМО с отказами заявка, поступившая в момент занятости всех каналов, получает отказ и покидает СМО. В СМО с очередью (или ожиданием) заявка, поступившая в момент занятости всех каналов, становится в очередь и ожидает освобождения одного из каналов обслуживания. Возможны СМО смешанного типа. Например, СМО с ограниченной очередью. В такой СМО заявка становится в очередь при занятости всех каналов, если очередь невелика и, скажем, не достигла длины m. Если все m мест в очереди заняты, заявка покидает СМО. К СМО смешанного типа относятся СМО с ограниченным временем ожидания. Заявка, поступившая в момент занятости всех каналов, становится в очередь, но уходит из СМО необслуженной, если время ожидания слишком велико.

Входящий поток в СМО как последовательность точек t 1, t 2,... t i моментов поступления заявок на оси времени Ot. Таким образом, случайные моменты времени t i (i = 1, 2, ...) поступления заявок в СМО распределены на оси времени со средней плотностью λ. Величина λ называется интенсивностью потока заявок и представляет собой среднее число (математическое ожидание числа) заявок, поступающих в систему за единицу времени.

Если имеется n каналов обслуживания (линий обработки заявок), на которые поступает поток заявок с интенсивностью λ. Поток обслуживания имеет интенсивность μ, которую называют интенсивностью потока обслуживания, μ означает среднее число заявок, обслуживаемых одним каналом в единицу времени. При этом под потоком обслуживания понимается поток заявок, обслуживаемых друг за другом одним непрерывно занятым каналом.

P_отк вероятность того, что заявка не будет обслужена;

k − среднее число занятых каналов обработки заявок;

Обозначим через S0, S1 ,…, Sn – состояния системы массового обслуживания заявок при функционировании системы управления инцидентами:

S0 − в системе нет заявок,

S1 − в системе одна заявка,

...........................................,

Sn − в системе n заявок.

Следующая заявка, пришедшая в систему, получит отказ.

pn − вероятность отказа системы: P_отк = pn.

Граф состояний системы технической поддержки представлен на рис.8, где:

λ – интенсивность входящих заявок;

μ – интенсивность обработки заявок;

n – число состояний системы;

Si - состояния системы, когда в ней находится i заявок.

Sk – состояния системы, когда канал занят;

Рис. 8. Граф состояния системы технической поддержки.

Представленный граф позволяет решить задачу расчета вероятностей переходов из состояния S_kв соседнее S_k−1.

Входящий поток заявок является простейшим с интенсивностью λ, поэтому переход из состояния S_iв S_i+1 происходит с одной и той же интенсивностью.

Переходы из состояния S_kв соседнее S_k−1 происходит с интенсивностью k μ (кратное количеству занятых каналов).

Интенсивность обработки заявок μ находится по формуле:

μ=1tсист

(1)

На основе распределения Эрланга вычисляется вероятность отказа p₀, когда система находится в состоянии S₀, и вероятность отказа p_i, когда система находится в состоянии S_i:

	(2)
	(3)

Если отношение λμ обозначить через ρ, то получим:

p0=(1+ρ+ρ22!+…+ρnn!) -1; pi=ρii!∙p0, i=1,2,…n

(4)

Величина ρ определяет среднее число заявок, приходящих за среднее

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

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

Pотк.=pi=ρii!∙p0

(5)

В результате можно найти среднее число занятых каналов обработки заявок в текущий момент времени по формуле (6):

k=ρ∙(1-ρnn!∙p0)

(6)

где k – среднее число занятых каналов в текущий момент времени; n – число каналов обработки заявок.

Полученные значения k и pотк позволяют рассчитать Nmin - минимально допустимое количество каналов обработки заявок при заданных ограничениях.

Формальная постановка задачи:

Решаемая задача представлена в следующем виде:

N →min,

где N количество каналов обработки заявок.

При ограничениях: P_отк< 0,01;

tсист≤5;

где: Pотк. - вероятность отказа в обслуживании;

tсист – это среднее время обслуживания;

n – количество каналов обработки заявок;

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

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

Рассмотрим решение поставленной задачи с использованием заданного набора исходных данных:

Имеется служба технической поддержки (СТП), которая может быть представлена как несколько автоматизированных рабочих мест с телефонной линией. Всего таких линий 5 (соответственно, число каналов n = 5).

Если заявка приходит в момент, когда все каналы заняты, то она получает отказ. Интенсивность потока заявок λ = 0,7 заявки, среднее время обслуживания одной заявки tобс = 3,4 мин.

Этапы решения задачи:

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

2. Определить число каналов, необходимых для обслуживания не менее 99% поступающих заявок.

Решение:

1. Обозначим через S₀, S₁, S₂, S_{3, S4, S5} −состояния СМО СТП:

S₀ − в системе все каналы свободны,

S₁ − один канал занят, 4 - свободны,

S₂ − два канала заняты, 3 - свободны,

S₃ − три канала заняты, 2 - свободны,

S₄ − четыре канала заняты, 1 - свободен,

S₅ − пять каналов заняты.

Следующая заявка, поступившая в СМО, получает отказ.

Граф переходов для состояний S₀ –S₅ представлен на рисунке 9:

Рис. 9. Граф переходов для состояний S0_{÷ S5}

1. Из условия задачи известно:

λ=0,7;

tобс =3,4 мин;

μ=1tобс=13,4=0,29 ;

ρ=0,7∙3,4=2,38

найдем необходимые значения вероятности отказа в обслуживании в состояниях S0 _{÷ S5}:

p0=1+2.38+2.3822!+2.3833!+2.3844!+2.3855!-1=0.096

pi=p0∙ρii! , i=1,2,3,4,5

p1=0,096∙2,3811!=0,228

p2=0,096∙2,3822!=0,271

p3=0,096∙2,3833!=0,215

p4=0,096∙2,3844!=0,128

p5=0,096∙2,3855!=0,06100

Тогда P_отк= p5 = 0,061.

Это означает, что в 6 % пользователей получат отказ.

Результаты расчетов позволяют сделать вывод, что при достаточно

высокой вероятности отказа в обслуживании, загруженность каналов обработки заявок составляет около 45%.

Так как по условию можно менять лишь один параметр (число каналов), то задавая значения n= 6 и n=7 получим значения для P_отк:

p6=0,096∙2,3846!=0,023

p7=0,096∙2,3857!=0,008

Pотк.(p6)≈2%

Pотк.(p7)≈1%

Следовательно, для того чтобы выполнялось неравенство:

P_отк< 0,01,

достаточно использовать 7 каналов, тогда всего 1% пользователей получат отказ.

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

Отсюда следует вывод, что если вероятность отказа в обслуживании меньше 0,01, т.е. обслуживаются не менее 99% поступающих заявок, то всего на рабочую группу Контакт Центра необходимо выделить 7 операторов.

1.  

   1. Разработка алгоритма решения задачи нахождения минимального

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

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

Например, имеется служба технической поддержки (СТП), которая может быть представлена как несколько автоматизированных рабочих мест с телефонной линией. Всего таких линий n. Для использования разработанного ниже алгоритма необходимо собрать данные по системе: интенсивность потока заявок λ, среднее время обслуживания одной заявки tобс, коэффициент загрузки системы ρ, интенсивность потока обслуживания μ, вероятность отказа системы, когда в системе нет заявок p0.

Если заявка приходит в момент, когда все каналы заняты, то она получает отказ.

Необходимо определиться с этапами решения задачи:

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

2. Найти предельные вероятности состояний.

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

Необходимо найти Nmin минимально допустимое количество каналов обработки заявок при заданных ограничениях: вероятность отказа в обслуживании должна быть менее 0,01. а среднее время обработки заявки не более 5.

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

Рис. 10. Блок-схема алгоритма решения задачи нахождения минимальногоколичества каналов обработки заявок при заданных ограничениях.

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

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

Рис. 11. Алгоритм управления инцидентами.

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

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

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

– проведение анализа назначенных на рабочую группу инцидентов с целью определения правильности назначения и контроля корректности, указанных оператором (диспетчером Контакт Центра) данных;

– распределение инцидентов по специалистам 2-й линии технической поддержки (инженерам);

– привлечение дополнительных ресурсов;

– контроль принятия в работу и времени выполнения инцидентов;

– формирование и направление на регулярной основе специалистам 2-й линии поддержки перечня стандартных вопросов, которые оператор (диспетчер КЦ) должен задать Контактному лицу при приёме Обращения;

– исходящие звонки и консультирование пользователей по решенным заявкам;

– консультирование из Базы прецедентов;

– актуализация Базы знаний по письму от специалистов 2-й линии;

– своевременное информирование об изменениях в системе, обновлениях или наблюдаемых технических сбоях (по письму от специалистов 2-й линии);

– составление отчетности о поступивших и направленных заявках, ведение счета обращений и инцидентов, обработанных оператором и специалистами 2-й линии;

– своевременное информирование специалистов 2-й линии о заявках, у которых истекает срок решения.

Согласно данному алгоритму, процесс управления инцидентами при большом потоке заявок рекомендуется организовать таким образом:

Координатор Контакт Центра (КЦ) с руководителем обеспечивают налаженность процесса управления инцидентами. Координатор КЦ определяет минимальное количество каналов обработки заявок, при котором учитываются введенные ограничения. Это количество находится по разработанной математической модели управления инцидентами. Для простоты расчетов необходимо воспользоваться блок- схемой алгоритма решения задачи нахождения минимального количества каналов обработки заявок при заданных ограничениях. Например, Nmin получилось равным 7, тогда выделяется 7 операторов для приема и обработки входящих заявок по телефону и по электронной почте, а несколько оставшихся операторов переводят на дополнительную линию поддержки, которая будет заниматься не входящими, а исходящими звонками и решением инцидентов по Базе прецедентов.

1-я линия технической поддержки в лице операторов (Диспетчеров Контакт Центра) обрабатывает входящий поток заявок.

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

– Время и дата создания обращения;

– Начальный статус = "Новое";

– Тематика вопроса;

– Номер (Уникальный ID номер заявки).

Оператор по информации от пользователя вносит в заявку:

– суть Обращения - "Краткое описание", которое должно заполняться краткими емкими формулировками.

– дополнительная информация по сути обращения "Описание".

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

В зависимости от сути обращения оператор может использовать различные шаблоны для его ускоренного оформления (например, "Замена картриджа", "Сброс пароля" и пр.).

До начала применения актуализированной Базы знаний необходимо произвести ее структуризацию. Так как в системе управления инцидентами есть определенная классификация обращений, то необходимо в Базе знаний указывать тематику вопроса, к какой услуге, предоставляемой технической поддержкой относится тот или иной вопрос, к какому приоритету относится, и какой срок по SLA выделен для решения проблемного вопроса. Если в Базе знаний информация будет структурирована таким образом, но можно провести привязку Базы знаний с системой управления инцидентами. Когда оператор классифицирует заявку, то круг вопросов относящихся выбранной тематики вопроса сужается, и время на поиск ответа в Базе знаний значительно уменьшится. С уменьшением времени поиска ответа в Базе знаний оператор может дать ответ пользователю за короткое время ожидания, что положительно влияет на продвижение очереди и ожидание ответа. В результате реализации такого функционала может повыситься процент решения заявок на линии операторов. Но если ответ не был найден в Базе знаний, то оператор передает заявку специалисту дополнительной линии, который пользуется Базой прецедентов, принимает в работу заявку и консультирует пользователя согласно информации из Базы прецедентов. Немаловажную роль играет подготовленность и структурированность информации передаваемой от специалистов 2-й линии на 1-ю линию поддержки для ознакомления. Так как в процессе приема большого потока заявок операторам недостаточно времени на ознакомление с нововведениями в работе, то информированием операторов занимаются специалисты дополнительной линии поддержки, таким образом, актуализируя информацию в Базе знаний в режиме реального времени. Специалисты дополнительной линии поддержки не принимают входящие звонки. Они обрабатывают заявки, которые специалисты рассмотрели, но еще не проинформировали пользователя по результату выполнения. Специалисты дополнительной линии должны искать заявки, у которых заканчивается предполагаемый срок выполнения, и информировать специалистов 2-й линии о наличии таких срочных заявок в системе управления инцидентами.

Вывод по 2 главе.

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

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

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

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

ГЛАВА 3. РАЗРАБОТКА МЕТОДИКИ И ОЦЕНКА ЕЕ ЦЕЛЕВОЙ ЭФФЕКТИВНОСТИ.

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

3.1. Разработка методики повышения эффективности инцидент-менеджмента.

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

Описание методики:

Шаг 1.

Производится расчет оптимального количества каналов связи с учетом ограничений. Для этого:

Шаг 1.1.:

Задаются исходные данные: интенсивность потока заявок λ, среднее время обслуживания одной заявки tобс, интенсивность обработки заявок μ, вероятность отказа в обслуживании p0 , среднее число заявок, приходящих за среднее время обслуживания одной заявки ρ. Выбирается начальное количество каналов обработки заявок N=1.

Шаг 1.2.

Производится расчет значения вероятности отказа в обслуживании pотк для различного числа каналов обработки заявок n.

Шаг 1.3.

Осуществляется проверка соответствия заданным ограничениям: вероятность отказа в обслуживании должна быть менее 1%. Требуется обслужить максимальное число заявок за время не более 5 минут.

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

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

Шаг 2.

Производится первичная регистрация обращения на 1-й линии в системе управления инцидентами, операторы классифицируют инцидент, задают приоритет – степень срочности (важности).

Шаг 3.

Осуществляется поиск решения в актуализированной Базе знаний, при нахождении решения пользователю оказывают консультацию.

Актуализация Базы знаний осуществляется специалистами 2-й линии поддержки.

Шаг 4, 5.

При отсутствии решения в Базе знаний специалисты передают инцидент на дополнительную линию поддержки.

Дополнительная линия поддержки не требует дополнительных специалистов извне. Она организуется после расчета оптимального количества каналов обработки заявок с учетом ограничений. После нахождения Nmin, часть специалистов 1-й линии, которая выделена с этого момента как дополнительная линия (не принимает входящий поток звонков) занимается исходящими звонками, а также консультированием пользователей по Базе прецедентов.

Шаг 6.

В случае отсутствия решения в Базе прецедентов инцидент передается специалистам 2-й линии поддержки.

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

Шаг 7.

Специалисты 2-й линии проводят диагностику состояния сервиса и при необходимости занимаются восстановление сервиса.

Дополнительной специалисты 2-й линии следят за обновлением, дополнением Базы знаний и Базы прецедентов необходимыми, актуальными решениями.

Шаг 8.

После восстановления сервиса инциденты возвращаются специалистам 1-й линии.

Специалисты 1-й линии информируют пользователя о проведенных работах.

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

Шаг 9.

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

Блок схема методики представлена на рисунке 12:

Рис. 12. Методика повышения эффективности инцидент-менеджмента.

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

Функции специалиста дополнительной линии технической поддержки:

– проведение анализа назначенных на рабочую группу инцидентов с целью определения правильности назначения и контроля корректности, указанных оператором (диспетчером Контакт Центра) данных;

– распределение инцидентов по специалистам 2-й линии технической поддержки (инженерам);

– привлечение дополнительных ресурсов;

– контроль принятия в работу и времени выполнения инцидентов;

– формирование и направление на регулярной основе специалистам 2-й линии поддержки перечня стандартных вопросов, которые оператор (диспетчер КЦ) должен задать Контактному лицу при приёме Обращения;

– исходящие звонки и консультирование пользователей по решенным заявкам;

– консультирование из базы прецедентов;

– актуализация базы знаний по письму от специалистов 2-й линии;

– своевременное информирование об изменениях в системе, обновлениях или наблюдаемых технических сбоях (по письму от специалистов 2-й линии);

– составление отчетности о поступивших и направленных заявках, ведение счета обращений и инцидентов, обработанных оператором и специалистами 2-й линии;

– своевременное информирование специалистов 2-й линии о заявках, у которых истекает срок решения.

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

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

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

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

3.2. Архитектура системы управления инцидентами с учетом разработанной методики.

При графическом представлении разработанная методика помещена в блок обработки заявок. Архитектура системы управления инцидентами представлена на рисунке 13.

Рис. 13. Архитектура системы управления инцидентами.

В архитектуре системы приведены несколько блоков. Блок входящих заявок поступает в автоматизированную телефонную станцию (АТС). А телефонный автоинформатор распределяет заявки по линиям, которые дают доступ к операторам. Операторы представлены в данной архитектуре как блок обработки заявок 1-го уровня. Данный блок обращается к Базе знаний, так и к Базе прецедентов. К блокам Базы знаний и Базы прецедентов имеет доступ также блок разрешения заявок 2-го уровня. Блок обработки заявок 1-го уровня соединяется с блоком разрешения заявок 2-го уровня с помощью разработанного блока обработки заявок, в которой представлена разработанная методика повышения эффективности инцидент-менеджмента. У блока разрешения заявок 2-го уровня имеются такие дополнительные блоки, как блок восстановления сервиса, блок диагностики. К заявкам доступ имеют два блока: блок обработки заявок 1-го уровня и блок разрешения заявок 2-го уровня.

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

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

Рис. 14. Обобщенный алгоритм функционирования системы управления инцидентами с учетом разработанной методики.

Когда поток обращений поступает в Контакт Центр, как видно из рисунка 14, все обращения проходят через АТС Службы технической поддержки. В обобщенном алгоритме раскрыт способ обращения пользователя в Контакт Центр по телефону. Но также пользователь может обратиться в Контакт Центр с обращением на бумажном носителе или по электронной почте. При необходимости обращение направляется с вложением/прикреплением.

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

Процесс регистрации заявки идет на 1-й линии, при этом оператором заполняются в заявке такие данные как:

- категория заявки (консультация, запрос на обслуживание, запрос на изменение, отзыв по качеству, не по адресу);

- направление (заполняется в соответствии с тематикой вопроса);

- вид услуги;

- приоритет заявки (критический, высокий, средний, низкий);

- срок, отведенный на решение заявки согласно SLA;

Оператор обращается к базе знаний. Если ответ в базе знаний найден, то производится консультация пользователя. Если ответ не найден, то специалисты обращаются к Базе прецедентов.

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

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

3.3. Оценка целевой эффективности разработанной методики.

Для проведения оценки целевой эффективности разработанной методики взяты данные работы службы технической поддержки за период с 12.05.2014 г. по 08.06.2014 г. В таблицах 6, 7 и 8 приведены данные мониторинга за указанный период.

Таблица 6.

Количество незарегистрированных заявок из числа принятых звонков.

Неделя № 1		Неделя № 2		Неделя № 3		Неделя № 4		За весь период
Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.	Принято звонков	Не зарег.
601	72	620	68	430	70	548	51	2199	261

Таблица 7.

Среднее количество пропущенных звонков из числа поступивших звонков.

Неделя № 1		Неделя № 2		Неделя № 3		Неделя № 4		За весь период
Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено	Поступило звонков	Пропущено
613	12	638	18	450	20	572	24	2273	74

Таблица 8.

Количество закрытых обращений с соблюдением крайних сроков

(«Да» - обращение просрочено; «Нет» - обращение не просрочено).

Неделя № 1		Неделя № 2		Неделя № 3		Неделя № 4		Открытые обращения на конец периода		За весь период
Да	Нет	Да	Нет	Да	Нет	Да	Нет	Да	Нет	Да	Нет
7	522	8	544	6	354	6	491	101	558	128	2469

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

Диаграмма 6 к таблице 6. Количество незарегистрированных заявок из числа принятых звонков.

Диаграмма 7 к таблице 7. Среднее количество пропущенных звонков из числа поступивших звонков.

Диаграмма 8 к таблице 8. Количество закрытых обращений с соблюдением крайних сроков («Да» - обращение просрочено; «Нет» - обращение не просрочено).

Проведен сравнительный анализ данных с данными полученными ранее за период 30.09.2013-27.10.2013.

Диаграмма 9. Сравнительная диаграмма по количеству незарегистрированных заявок.

Диаграмма 10. Сравнительная диаграмма по количеству пропущенных звонков.

Диаграмма 11. Сравнительная диаграмма по количеству инцидентов с нарушенным сроком выполнения.

Количество поступивших звонков в службу технической поддержки в период с 30.09.2013 по 27.10.2013 было больше в связи с сезонностью работ.

Диаграмма 12. Сравнительная диаграмма по количеству поступивших звонков.

Диаграмма 13. Сравнительная диаграмма по количеству принятых звонков.

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

Для оценки целевой эффективности использованы полученные данные:

х1 - Данные с 30.09.2013-27.10.2013;

х2 - Данные с 12.05.2014-18.06.2014.

∆ =x2-x1x1∙100% - формула оценки целевой эффективности.

∆'= 327-261261∙100%≈25.3%

∆' =25,3%- настолько снизилось количество незарегистрированных заявок.

∆'= 74-9090∙100%≈17.8%

∆' =17,8% - настолько снизилось количество пропущенных звонков.

∆'= 146-128128∙100%≈14%

∆' =14%- настолько снизилось количество инцидентов с нарушенным сроком.

В результате применения методики на 25.3%снизилось количество незарегистрированных заявок, на 17,8% снизилось количество пропущенных звонков и на 14% снизилось количество инцидентов с нарушенным сроком. Сравнительный анализ, проведенный для оценки целевой эффективности показал, что разработанная методика применима для повышения эффективности инцидент-менеджмента.

Вывод по 3 главе.

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

Методика состоит из 9 шагов, которые позволят выявить такое количество каналов обработки заявок, при котором поток заявок будет обслуживаться с вероятностью отказа в обслуживании в 1% и на обслуживание одной заявки уйдет не более 5 минут. В данной главе построена архитектура системы управления инцидентами, в которой отражены все компоненты (блоки) системы управления инцидентами и их связи. Предложенная методика в архитектуре системы управления инцидентами отражена в виде блока обработки заявок, который связывает между собой блок обработки заявок 1-го уровня и блок разрешения заявок 2-го уровня. Разработан обобщенный алгоритм функционирования системы управления инцидентами с использованием разработанной методики.

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

В результате применения методики на 25.3%снизилось количество незарегистрированных заявок, на 17,8% снизилось количество пропущенных звонков и на 14% снизилось количество инцидентов с нарушенным сроком. Сравнительный анализ, проведенный для оценки целевой эффективности показал, что разработанная методика применима для повышения эффективности инцидент-менеджмента.

ЗАКЛЮЧЕНИЕ

В магистерской диссертации решены следующие задачи:

• Разработана математическая модель управления инцидентами;

• Разработан алгоритм нахождения минимального количества каналов обработки заявок при заданных ограничениях, и разработан алгоритм управления инцидентами;

• Разработана методика повышения эффективности инцидент-менеджмента;

• Проведена оценка целевой эффективности разработанных предложений.

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

При анализе существующей модели управления инцидентами были выявлены такие недостатки как: ограниченное время для консультирования и обработки обращений; образование очереди при большом потоке заявок;

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

Для проведения точного анализа взяты результаты работы службы технической поддержки, которые показали, что среднее количество пропущенных звонков из числа поступивших звонков составляет 3,77%, количество незарегистрированных заявок из числа принятых звонков – 5,7%, а количество заявок, у которых истек срок выполнения – 81%.

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

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

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

В результате применения методики на 25.3%снизилось количество незарегистрированных заявок, на 17,8% снизилось количество пропущенных звонков и на 14% снизилось количество инцидентов с нарушенным сроком. Сравнительный анализ, проведенный для оценки целевой эффективности показал, что разработанная методика применима для повышения эффективности инцидент-менеджмента в информационной системе предприятия.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Сатунина А.Е., Сысоев А.С. Сервис-ориентированный подход к построению и функционированию корпоративной информационной системы //Журнал "Современные проблемы науки и образования", № 6, 2009. – С. 33-34 .

2. Аксенов В. и др. Глоссарий терминов и определений ITIL/ITSM. – 2009.

3. Ингланд Р. Овладевая ITIL. Пер. с англ. – М.: Лайвбук, 2011. – 200 с., С.22-28.

4. Балабанов П.В., Пономарев С.В. Разработка автоматизированной системы хранения и обработки информации: Методические указания. - Тамбов: Издательство ТГТУ, 2007.

5. В.Ю. Дмитриев. Эталонная модель НР по управлению информационными услугами. // Jet Info № 12, 2001. – 24 с.

6. Дунаев Г. Е., Михалев В.А. Особенности внедрения методологии ITSM, журнал «Открытые системы», № 1, 2004 г. (http://www.osp.ru/os/2004/01/044.htm)

7. Величко Т.В., Скачков П. П., Тимофеева Г.А. Математические модели массового обслуживания. Методические указания для студентов заочной формы обучения. – Екатеринбург, 2004. – 43 с.

8. Шерон Тейлор. Создание услуг высокого качества и управление ими. – itSMF, 2011. – 64 с.

9. Сатунина А. Е., Сысоева Л. А. Управление проектом корпоративной информационной системы предприятия. – М.: Финансы и статистика, 2009. – 352 с.

10. Н.Дубова. ITSM - новая идеология управления ИТ, "Открытые системы", №10, 2000. – С. 37-42

11. Н.Дубова. На пути у управлению ИТ-услугами, "Открытые системы", №7-8, 2000. – С. 49-57

12. Бирюков А.Н. Лекции о процессах управления информационными технологиями. Изд.: Интернет-университет информационных технологий, Бином. Лаборатория знаний. 2010. - 216 с.

13. О. Воронцов. Строим модель ИТ-управления, "Enterprise Partner. Корпоративные системы", №13, 2000 – С. 10-12

14. З. А. Алехин, ITIL - основа концепции управления ИТ-службами. Журнал «Открытые системы» №7-8, 2001. – С. 32-36

15. Сергей Догвань. ITIL на практике. Тема «ИТ-департамент на службе бизнеса» становится сегодня одной из самых популярных. Журнал «Открытые системы». ЗАО «Издательство «Открытые cистемы», №12, 2002.

16. Иван Мелехин. Управление инцидентами. JetInfo, №7, 2006.

17. Аппак М.А. Автоматизированные рабочие места на основе персональных ЭВМ. М.: Радио и связь, 1989.

18. Котляр Л.М., Вильданов А.Н. Оптимизация использования совокупных ресурсов информационной системы управления предприятием // Фундаментальные исследования.№ 5, 2004. – С. 22-25. http://rae.ru/fs/?section=content&op=show_article&article_id=7779649

19. Шикин Е.В., Чхартишвили А.Г. Математические методы и модели в управлении: Учебное пособие.- М.: Дело, 2000. - 440 с.

20. Хелдман К. Профессиональное управление проектом/Под ред. д.э.н., проф. И.М. Степанова.: БИНОМ. Лаборатория знаний. 2005. - 518 с.

21. Гнеденко Б.В., Коваленко И.Н. Введение в теорию массового обслуживания. 5-е, испр. изд. М.: Издательство ЛКИ, 2011. 400 с.

22. Клейнрок Л. Теория массового обслуживания. Пер. с англ. М.: Машиностроение, 1979, 436 с.

23. Емельянов С. Петровский А. Методы поддержки принятия решений. М. Изд.:Едиториал УРСС.Серия "Труды Института системного анализа Российской академии наук". 2005. - 152 с.

24. Больных A.A., Старых В.А. Автоматизация процессов управления сложным программно-аппаратным комплексом. «Информационные технологии и телекоммуникации в образовании и науке» (IT&T ES'2007): Материалы Международной науч. конф. / Редкол.: А.Н. Тихонов (пред.) и др.; ФГУ ГНИИ ИТТ «Информика». - М.: ЭГРИ, 2007. - С. 94-96. (статья из журнала, находящегося в перечне ВАК)

25. Больных A.A., Старых В.А. Разработка методики моделирования систем управления информационными системами: Всероссийская науч.-пракг. конф. «Технологии Интернет - на службу обществу». Сб. статей. - Саратов: СГТУ, 2005

26. Агибалов Г.П., Скутин А.А. Математическая модель и технология разработки безопасных корпоративных информационных систем // Электронный журнал "Исследовано в России", 4, 1739-1750 , 2001. http://zhurnal.gpi.ru/articles/2001/151.pdf (статья из журнала, находящегося в перечне ВАК)

27. Захарушкин В.Ф. Особенности создания информационного обеспечения корпорации // Электронный журнал "Исследовано в России", 6, 718-725 , 2003. http://zhurnal.gpi.ru/articles/2003/062.pdf (статья из журнала, находящегося в перечне ВАК)

28. Иващенко А.В., Сталькин А.А., Калышенко У.М. Применение методологии UML при автоматизации управления бизнес-процессами // Электронный журнал "Исследовано в России", 7, 1049-1053, 2004. (статья из журнала, находящегося в перечне ВАК)

29. Больных A.A., Абрамович И.В. Анализ методов управления корпоративными информационными системами / Дистанционное и виртуальное обучение. - 2008. - №4. -Изд-во СГУ, 2008. - С. 74-76.

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

31. Алехин З. А., ITIL - основа концепции управления ИТ-службами. Журнал «Открытые системы» №7-8, 2001. – С. 32-36.

32. Балабанов П. В., Пономарев С. В. Разработка автоматизированной системы хранения и обработки информации: Методические указания. - Тамбов: Издательство ТГТУ, 2007.

33. Дмитриев В. Ю. Эталонная модель НР по управлению информационными услугами. // Jet Info № 12, 2001. – 24 с.

34. Беркетов Г.А., Микрюков А.А., Федосеев С. В. Решение задачи выбора лучшего варианта из заданного набора с использованием теории нечетких множеств. Сб. трудов научно-практической конференции «Инновации в условиях развития информационно-коммуникационных технологий» Инфо -2009, г. Сочи, 2009. – С.144-146.с.

Код для цитирования: Скопировать